With more companies than ever leveraging cloud services like AWS, and with cloud environments becoming more and more complex, it’s imperative that organizations develop comprehensive, proactive security strategies that build security in from Day 1 and evolve as their infrastructures scale to keep systems and data secure.
To help as you create a strong security posture for your organization, we’ve compiled a list of 101 AWS security tips and quotes from cloud experts and security thought leaders (including a few from Threat Stack).
To make the list manageable, we’ve divided it into four separate blog posts, which we’ll publish over the next few weeks:
- Part 1: Essential Security Practices
- Part 2: Securing Your AWS Environment
- Part 3: Best Practices for Using Security Groups in AWS
- Part 4: AWS Security Best Practices
Today we’ll keep the focus on:
Essential Security Practices
1. Putting strategy first enables you to determine if (and how) controls and tools support your overall strategy.
“A big question we see bubbling up among AWS security user groups and forums (like this one on Quora) is how to approach cloud security in the first place. More specifically, do you put tools and controls in place first, or take the time to establish your security strategy? While this seems like an elementary discussion, the answer is more complicated.
“Nine times out of ten, the strategy should come first, so that when assessing a control or tool, you can better determine if and how it supports your strategy. Putting the strategy first also enables you to integrate security into all business functions — including those reliant on AWS. This can be a huge help with continuous deployment, in particular. For example, if your organization is using (or considering using) configuration management tools (e.g., Chef, Puppet, Ansible, Salt) to enable the automation of software updates and patches, having an overarching security strategy can help you implement security monitoring across these tools from day one. The same approach applies to any business process or tool you use across your organization.”
— Pete Cheslock, The Top 7 AWS Security Issues: What You Need to Know, Threat Stack; Twitter: @threatstack
2. Plan your strategy before setting up tools and controls.
“Once your cloud security strategy is well in place, while setting-up all the tools and controls, you can easily verify to ensure that their installation supports your security strategy. This goes a long way in helping you integrate the security strategy across all your organizational functions. Also, when you already have a security strategy in place, on installing a new set of tools you can implement this strategy to these tools as well right from the day one.”
3. Know what you are responsible for when working with any cloud provider.
“All cloud services are not the same, and the level of responsibility varies. Software-as-a-service (SaaS) providers will make sure their applications are protected and that the data is being transmitted and stored securely, but that is typically not the case with cloud infrastructure. For example, the organization has complete responsibility over its AWS Elastic Compute Cloud (EC2), Amazon EBS, and Amazon Virtual Private Cloud (VPC) instances, including configuring the operating system, managing applications, and protecting data.
“In contrast, Amazon maintains the operating system and applications for Simple Storage Service (S3), and the organization is responsible for managing the data, access control and identity policies. Amazon provides the tools for encrypting the data for S3, but it is up to the organization to enable the protection as it enters and leaves the server. Check with the provider to understand who is in charge of each cloud security control.”
4. Create written, consistent cloud security controls and procedures.
“All of the recent S3 breaches have involved S3 buckets that contained sensitive data and that had been set to public. By default, S3 buckets are set to private, meaning that only the account owner can access their contents. Buckets are not set to be publicly viewable by accident; someone with the privileges to do so must go into the system and take specific steps to override the default setting. This begs two questions: Why was this sensitive data sent to the cloud in the first place? Why did someone override the default and make them public?
“A set of written cloud security controls and procedures clearly defines which types of data are to be stored in the cloud, how long they are to be kept there, and where they belong in the cloud storage hierarchy. Not only should sensitive information never be placed in a public S3 bucket, but also, access to buckets containing sensitive information should be highly restricted. This leads to the next best AWS S3 security best practice.”
5. Apply security to ALL layers.
“One of the things many professionals forget to do is to beef up their security systems. Don’t just have one firewall in the infrastructure but take all security measures. Have virtual firewalls on all your virtual networks for added security. These are available to install from the AWS Marketplace. It is an investment worth making to keep all your information safe.”
— Vinay Prajapati, Seven Tips that Every IT Professional Must Know for AWS Security, TechPrevue; Twitter: @techprevue
6. Take advantage of native cloud security resources.
“In AWS, there are a host of native security tools to help you achieve a secure environment. And with standard compliance frameworks, such as the ISO/IEC 27000 series, and Amazon Machine Images (AMIs) preconfigured with varying compliance elements built in, there is a lot of front-end work already done for you.”
7. Integrate Security into DevOps.
“There’s no denying that we are in the midst of a major security talent crunch. There are not enough security experts on the market, and it’s hard to find candidates who are skilled in the latest tools and technologies. Even when teams manage to hire good security people, the ones that can code often get stolen by development teams.
“The good news is that you can make security happen whether you have a full security operations center (SOC) or no infosec employees at all. In a modern organization, security should not just be the responsibility of analysts or even SecOps teams; it should be a team-wide, top-to-bottom effort. And keep in mind, the better your tools and processes, the fewer experts you’ll need.”
— Pete Cheslock, The SecOps Playbook: What I’ve Learned About Integrating Security Into DevOps, Threat Stack; Twitter: @threatstack
8. Know who is accessing your database and for what purposes.
“In order to fully understand the security aspects of a database, you need to examine who is accessing the database and for what purposes. Remember to think beyond regular user access. For example, administrative tasks should be mapped out to ensure that granular access controls will be maintained after moving to the cloud.
“If the application uses external data sources, you may require new controls, such as data-in-motion encryption and data integrity validation, in order to retain data confidentiality and integrity as this data moves from those sources into the database.”
— David Maman, Security Best Practices for Migrating your Database to the Cloud, HexaTier; Twitter: @HexaTier
9. Define user roles.
“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.”
— Romulo Salazar, Cloud Security Best Practices for Amazon Web Services (AWS), Praetorian; Twitter: @praetorian_inc
10. Configure a password policy.
“Password policy is a setting, which describes the conditions of password rotation between active users and deletion policy for old or inactive users. It’s usual for companies to stick to their current off-line password policy and set the password strength and the timeframe for password expiration in AWS accordingly. To protect the data, you should regularly re-use credentials with different users or delete them and set a new key pair.”
11. Encrypt sensitive information.
“AWS always encourages customers to encrypt data, and contrary to popular belief, encryption won’t slow anything down. Enabling encryption in AWS is as simple as checking a box if you choose their native encryption, which provides end-to-end SSL/TLS and HTTPS for AWS Service APIs.
“Additionally, you may want to implement scalable key management to create, rotate, define, and audit your encryption keys in one place.”
— Tim Armstrong, Best Practices for Implementing & Scaling Security in AWS, Threat Stack; Twitter: @threatstack
12. Use both server- and client-side encryption.
“Another preventative step to take with any cloud-based data is to encrypt it before moving to the cloud and within the cloud. Cloud providers usually offer encryption for traffic at rest, but you must enable it in storage, database, and file services including as Amazon EBS and Redshift or Azure RMS for file-level encryption.”
— Cloud security best practices: part 2 Shared Responsibility, Cohesive Networks; Twitter: @cohesivenet
13. Take steps to protect data in transit and at rest.
“AWS offers accessibility of data stored on S3 via SSL encrypted endpoints, which helps developers to protect data in transit as well as at rest. AWS also takes certain steps while decommissioning of storage devices to ensure maximum data security, for example storage devices are Degaussed or Physically Destroyed (based on the type of device) before it’s moved out of any AWS region. So one can be assured that data even on an end of life hardware would not be exposed to unauthorized usage.”
— Gurmeet Singh, Understanding Security Best Practices on AWS Cloud, BlazeClan; Twitter: @cloudITbetter
14. Have only one SSH key per person, and never create shared SSH keys.
“It’s best to have only one key per person, even across different laptops and desktops. When you have to upgrade your laptop, don’t generate a new SSH key, instead, transfer the old one to your new laptop and delete it from the old one.
“Never, ever, create a shared SSH key for multiple people to use.”
15. Don’t use expired certificates.
“Avoid using expired SSL/TLS certificates because they may no longer be compatible with AWS services, leading to errors for ELB or custom applications, impacting productivity and overall security.”
— Sekhar Sarukkai, Surviving the Fallout of the Deep Root Leak: Best Practices for AWS, Data Center Knowledge; Twitter: @datacenter
16. Backup your data.
“Every organization requires a unique backup architecture. Amazon Web Services offers flexible backup and restore solutions to fit your data and regulatory needs. Your AWS backup strategy depends on the nature of your data, your current IT setup and industry requirements. Taking an umbrella approach to data backup and restore exposes your organization to potential failed backups and data loss.”
— Developing a Foolproof AWS Backup Strategy to Prevent Data Loss, AgileIT; Twitter: @Agile_IT
17. Segment your AWS environments when using VPCs.
“Avoid lumping disparate systems into one, big, flat network. Developers don’t put production, staging and test/dev systems onto the same corporate network, so don’t put them in the same VPC. Likewise, different application tiers probably don’t have the same security policy — web front ends and critical databases shouldn’t live in the same subnet.”
— Kurt Marko, Amazon VPC best practices to kick security up a notch, SearchAWS; Twitter: @TechTarget, @krmarko
18. Use EBS Encryption.
“EBS stands for Elastic Block Store and is used to store persistent data for your EC2 instances. Think of it as hard drives attached to your EC2 instance. EBS is different from S3 in that it can only be used in conjunction with EC2. The huge upside to using EBS encryption is that you can turn it on with no performance penalty. And it only requires you to select a check box to enable it. If anyone ever gets access to your previously used volumes, there’s no way they can access any of the data on them.”
— Pete Cheslock, 3 Things You Can Do to Improve Your AWS Security Posture, Threat Stack; Twitter: @threatstack
19. It’s up to you to manage access properly, so implement sound access control policies and procedures from the start.
“When you create your AWS Account, you will have an AWS Administrator account and credentials that will allow you to create other users, groups, and roles within the Identity & Access Management (IAM) Service. Right from the get-go, you are in control of who can access your resources, and it’s up to you to manage this access properly. IAM is a very powerful tool that you can use to create a very specific set of access permissions and private security keys for the resources you deploy. Within IAM, you can also implement Multi Factor Authentication, something I strongly recommend for ALL of the administrator accounts that you create, and especially the admin account.”
20. Lock down your root account credentials.
“Root account credentials provide users with full access to the resources in the account. As a best practice, delete the root account access keys and create an Identity and Access Management (IAM) admin user instead. In addition, enable multifactor authentication (MFA) for another layer of protection.”
— Chris Preimesberger, 11 Simple Yet Important Tips to Secure AWS Deployments, eWeek; Twitter: @eWEEKNews
21. Keep your AWS policies and practices up to date.
“Imagine you have a very specific file structure set up in the cloud, complete with categorical folders that are protected by different levels of permission. You know that all company sales data should go in a specific folder, but a coworker, though meaning well, doesn’t know and decides to transfer sales data to a different, unprotected folder. Chaos ensues.
“To avoid this type of confusion, create consistent cloud practices everyone can follow. Document your AWS processes and procedures. Store them in a common space that the organization can access, like a shared drive on the internal network. And update the document every time something changes in your cloud approach to help coworkers, stakeholders, third party vendors, and trading partners remain on the same page.”
— 7 Cloud Security Best Practices for Amazon Web Services, GoAnywhere; Twitter: @GoAnywhereMFT
22. Extend your common security model.
“Conventional security and compliance concepts still apply in the cloud. Whether we’re talking about existing apps migrating to the cloud or new ones being built there, they must be secured and good practices still apply. You can minimize the time and resources required to achieve this by leveraging the processes and technologies already in place within your organization.”
— Andy Smith, Moving to the Cloud? Six Best Practices for AWS Security, Centrify; Twitter: @Centrify
23. Leverage vulnerability reporting.
“AWS educates their users on refraining from clicking on any links, entering passwords or downloading attachments through email. Instead, use Amazon’s system to report suspicious emails to keep your company safe. Reporting information can help create a culture of security in your office, and alert AWS to which vulnerabilities may be impacting your business.
“Aside from alerting Amazon to phishing scams and potential hacking, you can also report illegal hacking to the proper authorities. The U.S. Department of Justice details how to report different types of hacking, from intrusion to password trafficking. Depending on the hacking crime, an FBI local office, the U.S. Secret Service or Internet Crime Complaint Center may be your best point of contact.”
24. Keep your servers patched.
“Like any of your other machines, you want to keep your AWS cloud servers patched. This still applies even if the systems aren’t really publicly accessible. The same goes if you’re only using the servers for test and dev. You still want them patched.
“If your AWS servers aren’t current, there should be a very strong reason. It’s just too much of a risk and it is an easy solve. Leverage a SaaS-based patching solution such as Automox to cover your AWS cloud server patching.”
25. Use key policies to control access to CMKs in AWS KMS.
“Key policies are the primary way to control access to CMKs in AWS KMS. Each CMK has a key policy attached to it that defines permissions on the use and management of the key. The default policy enables any principals you define, as well as enables the root user in the account to add IAM policies that reference the key. We recommend that you edit the default CMK policy to align with your organization’s best practices for least privilege. To access an encrypted resource, the principal needs to have permissions to use the resource, as well as to use the encryption key that protects the resource. If the principal does not have the necessary permissions for either of those actions, the request to use the encrypted resource will be denied.”
26. Implement tight controls on user access.
“Who has access to your AWS cloud infrastructure is a critical issue. Some organizations will tell you to use a bastion host or jump server. We’d advocate a much tighter method where you are controlling access on each system.
“You are required to use SSH keys with AWS cloud servers, and that’s a great start. But you need a system to help control that access. Manually managing access and keys is a recipe for disaster. Controlling user access may be one of the most critical aspects of AWS security.
“Many sysadmins will opt for using Chef or Puppet to automate their user management, but we suggest implementing a cloud directory service. This solution integrates identity management across your on-prem and cloud infrastructure, which means that you have a single identity across your on-prem systems, applications, and WiFi, as well as on your cloud servers. In addition, when a user is removed from your cloud directory, they are terminated everywhere ensuring that they can’t access your critical cloud servers. Directory-as-a-Service will help solve your user access problem for you.”
27. Don’t neglect network security.
“Rules of computer networks in traditional data centers apply to cloud as well. You need to define how computers (or instances in AWS lingo) are connected and talk to each other over networks.”
28. Use password generator tools to create super-secure passwords.
“Have a super complex password policy in place. AWS allows you to enforce the complexity in IAM password policy section. I would even advise that for all logins you create on AWS, use a password generation tool like this. No matter how secure you think your birthday, car registration no. or anniversary date it, it can always be hacked. So set non-sensical, non-dictionary based password which have a mix of upper & lower cases, special characters, numbers et. al.”
— Adil Shaikh, The Most Basic Security Best Practices for AWS, Geeky Central
29. Choose regions to manage network latency and regulatory compliance.
“AWS provides information about country and state where each region resides. It is your responsibility to select the region to manage network latency and regulatory compliance.”
— Naresh Madiraju, Security Best Practices, nxgcloud
30. Management of AWS resources and instances occurs in the AWS Management Console, and access to this management plane is like having keys to the kingdom.
“Management of AWS instances and resources are performed using the AWS Management Console. Some of the main activities that can be conducted using the AWS Management Console are creating new virtual machines and removing any existing virtual machines and other AWS services. Monitoring the unauthorized access to AWS Management Console is critical since gaining this convenient access to the cloud management plane is like having keys to the cloud kingdom.”
31. Use AMIs for platform components.
“Use AMIs (Amazon Machine Images) instead of configuring a WordPress machine or a Linux Server from scratch. Buy a pre-hardened AMI for your system components to skip the security configuration work and reduce risk.”
— Laura Levy, 14 Tips for Implementing the AWS Shared Responsibility Model, Trusted Knight; Twitter: @trustedknight