This is the first in a series of blogs dedicated to Amazon Web Services (AWS) security monitoring and best practices.
AWS Security Best Practices
As more and more organizations of all sizes are moving applications and workloads to the public cloud, it is critical to understand the security challenges of the cloud in general, and AWS in particular. IT environments are increasingly hybrid in nature, with many organizations maintaining some on-premises infrastructure as well as cloud infrastructure, using one or more cloud providers. It is critical to leverage security solutions that can monitor both cloud and on-premises environments.
Here are some simple yet important tips to help secure your AWS account and infrastructure:
- Lock Down Your Root Account Credentials: When you create an AWS account, it comes with root account credentials. You can use these credentials to access all resources in the account (full access). Our recommendation is to delete the root account access keys and create an Identity and Access Management (IAM) admin user instead. Note, you will still need root account access for critical users to perform certain operations, and you can still access the root account using the username/password on the AWS console. As a final recommendation, you should enable multi-factor authentication (MFA) to protect your account.
- Use Security Groups: Use AWS Security Groups to limit access to administrative services (SSH, RDP, etc.) as well as databases. In addition, try to restrict access and allow only certain network ranges when possible (and avoid using 0.0.0.0/0). It is also important to monitor and delete security groups that are not being used and to audit them periodically.
- CloudTrail: AWS CloudTrail is a critical resource for monitoring your AWS environment. CloudTrail logs every event related to your AWS infrastructure, including API calls and changes made from the AWS Console, SDKs, or command line tools. While CloudTrail contains an amazing level of detail related to your AWS account activity, it is often hard to understand all the events and to identify what is important from a security point of view. That is why the CloudTrail data is much more valuable when using a solution such as USM Anywhere that has out-the-box correlation and alerting capabilities for CloudTrail events.
- IAM Roles and Temporary Credentials: IAM roles can be used to define permission levels for different resources and applications that run on EC2 instances. When you launch an EC2 instance, you can assign an IAM role to it, eliminating the need for your applications to use AWS credentials to make API requests. This is one of the best tools when it comes to security in AWS. First of all, IAM roles can be very granular; you can control access at a resource level and for actions that can be performed. And when using IAM roles, if your EC2 instance gets compromised, you do not need to revoke credentials.
- Use Virtual Private Cloud (VPC): An Amazon Virtual Private Cloud (or VPC) is a virtual network that runs in your AWS account. This virtual network presents some key advantages from a security point of view: the network is isolated from other resources, it is not routable to the Internet by default, and you can apply security groups and access control lists to reduce the attack surface.
- Implement A Bastion Host: A bastion host provides access to your Linux instances deployed in a private subnet of your VPCs. The bastion host removes the need to expose the SSH service of your Linux instances and it centralizes SSH access to every system. This allows you to reduce your attack surface and to simplify access control, auditing, and monitoring of SSH access.
- Scan For Vulnerabilities: It’s important to know that you can’t launch network scans or perform penetration tests in your AWS infrastructure. You need to ask Amazon for permission first. That being said, you can scan your EC2 instances for vulnerabilities if your vulnerability scanner allows you to launch authenticated scans that check for vulnerabilities after logging into the system.
- Protect EC2 instances against accidental termination: By default, when you deploy a new EC2 instance, it can be terminated via the console or the API. A good practice is to enable “Termination Protection” in your instances. This will prevent accidental terminations that have been known to happen.
- Activate RDS Encryption: When deploying your databases into AWS RDS (Amazon Relational Database Service), remember to check the “Enable Encryption” checkbox. This is easily done without customization, and it adds another layer of security to your RDS workloads.
- Use Load Balancers: When deploying web workloads, it is a good practice to use Elastic Load Balancers. This not only helps you with auto-scaling but also allows you to encrypt your traffic, store access logs, and even use AWS’s Web Application Firewall (WAF) services out of the box – very nice!
- Activate VPC Flow Logs: VPC Flow Logs allow you to record information about the network traffic going through your VPCs. You can create VPC Flow Logs from a network interface, a subnet, or the VPC itself. This will generate a flow log for each network flow, containing information such as the source and destination address, source and destination port, number of packets, bytes, duration, and whether or not the traffic was accepted or rejected. The VPC Flow Logs can be used to detect suspicious traffic, check for Indicators of Compromise (IOCs), and help during an incident response or a forensic analysis after an incident. You can use AlienVault OTX to investigate IOCs.
That wraps it up for today. In upcoming installments of this series, I will continue to share ideas and best practices for securing your AWS accounts and infrastructure that will help you ensure a successful and secure AWS implementation. More to come!