Cloud adoption has grown rapidly. Although cloud computing is now considered to be mainstream, security-related cloud adoption challenges persist. Cloud security is very important for any organization, irrespective of size, and digital engineering teams should always check from the get-go that their service providers can provide the correct security levels for their cloud workload. Because security is such an essential element of an organization’s cloud service, it is up to organizations, working in partnership with their cloud service provider, to really understand the different security roles, responsibilities, tools and best practices.
Getting the balance right security-wise is getting easier. Take, for example, AWS which has published its cloud security best practices to help customers implement cloud services in a highly secure manner. This help provide a steer to organizations unsure of the tools or services they require. The AWS cloud platform allows customers to scale and innovate while maintaining a secure environment. Customers only pay for the cloud security services they are using without any upfront expenses, unlike the on-premises environment.
When it comes to cloud security SNAFUs, misconfigurations that accidentally and unnecessarily expose services are the biggest culprits. Any misconfigurations during implementation can potentially lead to huge damage down the line. In the cloud, resource provisioning, management, and monitoring happen via APIs, console, and CLI. So, it’s essential to secure all these connections during the early stage of cloud adoption.
In addition, teams must ensure that virtualization, identity, and access management (IAM), workload protection, and network security and encryption are a part of this architecture blueprint. We are all familiar with catastrophic data breaches that make the news, but there are many others that do not, and the vast majority of these are avoidable. Let’s examine the following three scenarios, all derived from real experiences, and the look at how the vulnerability could have been avoided.
Case 1: Passwords matter
The account was compromised due to a weak root user password, combined with MFA not being configured. An attacker removed EBS, EC2 instances, S3 data backup, and asked for a ransom to provide the database backup file.
This could have been prevented by utilizing an IAM user with a specific policy instead of using the root account.
Case 2: Visible access keys
The developer posted the development account credentials for the AWS access and secret access key in the script, which was on the public git repository. Using those keys enabled the attackers to deploy multiple resources in all regions and created lots of dummy resources. For the six to eight hours that the account was hijacked, the attackers racked up a bill of $4,000-5,000.
This could have been prevented by using an IAM role instead of hard-coding the access keys into code. Access keys should be rotated periodically.
Case 3: Mis-configurations
The security group was not properly configured. In particular, port 22 was allowed globally, ports 80 and 443 were also open from all. The application which was hosted on EC2 instance was front-ended by the application load balancer. The attackers found a basic cross-site scripting vulnerability and SQL injection, tried injecting malicious scripts, and removed all the data from the server.
This could have been prevented by following a trusted advisory, putting WAF on top of the application load balancer, and utilizing the AWS inspector for security assessments.
These three cautionary tales are all examples of where a small security vulnerability caused big losses, and they all demonstrate how easy it would have been to deploy the secure cloud option. Hindsight is a wonderful thing, but it is even better to avoid making the error in the first place. Below we have compiled our 11-step guide to understanding security best practice structures and how users should implement the AWS platform and its services in the best way.
Step 1: Understand the Shared Responsibility Model
- Amazon’s responsibility: AWS is focused on infrastructure security, including computing, storage, database, and intrusion prevention networking services. AWS is also responsible for the security of the software, hardware, and the physical facilities that host AWS services.
- Customer’s responsibility: AWS customers are responsible for the secure usage of AWS services that are considered un-managed. The customer is responsible for managing user base access-authentication methods, encryption of data stored inside AWS.
Step 2: Follow IAM Best Practices Including –
- The AWS Identity and Access Management Service enables users to manage access to AWS services and resources securely.
- The AWS account can be administrated by creating groups and users and applying granular permission policies to users to provide limited access to APIs and resources. You can watch this video for a deep dive into IAM policy management.
- When granting IAM roles, follow the “least privileges” approach to security.
- Rotate access keys and passwords.
Step 3: Manage OS-Level Access and Keep EC2 Instances Secure
- Run an inspector assessment to generate an OS-level vulnerability report.
- Use System Patch Manager to keep OS packages updated.
- Patch the EC2 instance periodically to protect your infrastructure from newly discovered bugs and vulnerabilities.
- Follow the security advice provided by OS vendors like RedHat, Suse, Microsoft, etc. This helps to keep all OS-specific packages updated from a security perspective.
Step 4: Encryption!
- There are two methods for encryption in AWS: in transit and at rest.
- Use AWS KMS for storing at rest encryption keys, which can be AWS generated or customer-generated.
- Use Cloud HSM to provide hardware-encrypted devices for storing keys.
- Most AWS services provide in-transit encryption by providing https endpoints that provide encryption end-to-end.
- AWS Certificate Manager allows you to create an SSL certificate for the public domain
Step 5: Follow Security Best Practices for AWS Database and Storage Services
- RDS storage should be encrypted at rest.
- Restrict access to RDS instances to decrease the risk of malicious activities such as brute force attacks, SQL injections, or DoS attacks.
- S3 storage should be encrypted at rest.
- S3 policy should be used to restrict access to S3 content. Keep your S3 bucket private if you don’t have any requirement to expose objects.
- Use AWS Macie to detect and secure sensitive data within AWS-S3.
- Use the AWS Parameter Store to store environment-specific credentials and secrets, which you can easily achieve using secrets management for your cloud-native application.
Step 6: Network Security
- Intrusion detection systems (IDS) or Intrusion prevention systems (IPS) allow us to detect and prevent critical Infrastructure like payment gateway of banking-related transaction applications.
- VPC flow logs should be enabled to monitor network traffic.
- Restrict access by security group (EC2, RDS, Elastic Cache, etc.)
- Use Guard Duty to monitor AWS accounts and infrastructures continuously.
Step 7. Web Application Security
- Web application firewalls (WAF) provide deep packet inspection for web traffic.
- WAF can also help to prevent platform and application-specific attacks, protocol sanity attacks, and unauthorized user access.
- Amazon Inspector is an automated security assessment service that improves security and compliance of applications deployed on AWS.
- Use AWS Cognito to authenticate application user pools securely. It also supports federated access from Google, Amazon, and Facebook, etc.
Step 8. Enable Configuration Management
- AWS Config helps to audit, assess, and evaluate the configuration changes within AWS.
- Customers can also rely on third-party configuration management tools, which can provide more granular visibility.
Step 9. Monitoring and Alerting
- CloudTrail enables auditing and monitoring of authorized and unauthorized activities within the AWS account.
- CloudWatch alerts can be set up for malicious activities within the AWS account, and infrastructure deployed inside AWS and application logs.
- Set billing alarms to keep your team aware of the cost utilization of specific accounts or infrastructure.
Step 10: Compliance
- AWS Artifact helps customers to get a no-cost, self-service portal for on-demand access to AWS compliance reports.
Step 11: Training and Certification
- Train and educate teams using the AWS cloud platform for deploying or are responsible for the infrastructure.
If you have any questions surrounding the cloud security best practice guidelines, or you have additional security queries, get in touch with Apexon. Let us know your toughest security dilemma, and we’ll help you solve it.