8 Spooky AWS Security Mistakes You Should Avoid This Halloween

Who doesn't love a good Halloween scare? But there's one type of spooky surprise that you definitely don't want on a full-moon night — or any night for that matter.

‍

AWS has a million different security knobs and levers you can pull, so it's hard to know which ones do what. But if you accidentally misconfigure an IAM policy and leave it open to privilege escalation...*shudder*.

‍

We want your Halloween filled with the right kind of spooks, full of fake blood and squishy prosthetic vampire teeth. NOT a leaky public S3 bucket revealing all your files to the public.

‍

Here are 8 of the spookiest AWS security mistakes you should avoid this Halloween:

‍

Mistake #1: Not rotating access keys regularly

In most cases, having long term credentials is a bad idea. The longer your account goes without the access keys changing, the more prone it becomes to compromise.

‍

But in the (hopefully rare) case where you have an IAM user who needs long-term credentials, use access key last used information to rotate and remove access keys regularly.

‍

You can rotate access keys from the AWS Management Console. To see if your access keys are due for a rotation, open your IAM Console and go to Users. You should rotate your access keys regularly, i.e. approx. every 90 days.

‍

Mistake #2: Ignoring your CloudTrail logs

Configuring security features and IAM policies is crucial, but what about once your application is deployed? That's when the next stage of cloud security kicks in: logging and monitoring. Visibility into your AWS environment is critical in order to look for malicious activity and secure against it.

‍

AWS CloudTrail is a monitoring and logging service that records account activity across your AWS infrastructure. It not only lets you log user activity and events, but helps you analyze the log data and remediate insecure APIs and endpoints.

‍

Ensure you properly monitor and log all activity in your AWS environment, and don't forget to regularly check the logs. Note that without configuring a CloudTrail trail, it only lets you view event history for the last 90 days.

‍

Want to learn this hands-on? We've got a course on AWS Monitoring & Logging with CloudTrail.

‍

Mistake #3: Not enabling Amazon GuardDuty

To build off the last point, threat detection is one half of the cloud monitoring coin. In AWS, that side comes in the form of Amazon GuardDuty.

‍

GuardDuty is a continuous threat detection service that analyzes CloudTrail logs, VPC flow logs, DNS logs, EKS audit logs etc. to identify malicious activity in your AWS environment. It helps you protect against malware, suspicious activity, and can even monitor Kubernetes clusters.

‍

Make sure you enable GuardDuty in all supported AWS regions (it's a regional service). It works with CloudTrail to collect findings on the security posture of your AWS infrastructure. Routinely check the findings and remediate issues as soon as you see them.

‍

Mistake #4: Using long-lived credentials

As we mentioned in Mistake #1, long-lived credentials do have some utility. Outside of rare exceptions, however, you should go totally nuclear and allow access only via temporary credentials.

‍

Giving your IAM users federated access to their AWS accounts. You can use AWS Single Sign-On (AWS SSO) to manage centralized access and permissions.

‍

For third party apps and services (non-human 'users'), you can use IAM Roles Anywhere to give them access with temporary credentials. IAM Roles Anywhere uses the same IAM policies and roles you use with AWS to access your resources.

‍

Mistake #5: Giving public S3 buckets 'leaky' permissions

Amazon Simple Storage Service (S3) is one of the primary ways you'll be storing and retrieving data on AWS. But why have S3 buckets exposed to the public? In cases where traffic to your app is too high and you want to offload some traffic to a content delivery network (CDN), public S3 buckets come in very handy.

‍

But without the proper security measures, that's just asking for trouble. Users might be able to list all the files in your bucket, or even access every single file without authentication.

‍

One way to avoid this, according to Bernhard from Comsysto Reply, is to use 'secret' URLs that can't be guessed. This isn't 100% secure, but is usually good enough if you want to keep the S3 bucket public. You can use a hashing algorithm (like SHA512) to hash the UserIDs, keeping the URL obfuscated and unguessable.

‍

Note that this is NOT a secure way to deliver sensitive data. Only use this where the data can be publicly accessed/is not sensitive.

‍

Get hands-on with Amazon S3! Check out our full course right now.

‍

Mistake #6: Giving users or roles too many permissions

The worst thing you can do for your AWS IAM is to give up and just give every user or role broad permissions. Privileges ought to be jealously guarded, and being cavalier with access management is always a bad idea.

‍

Follow the principle of Least Privilege when assigning roles and permissions to users. IAM policies are set to deny by default, and you should only give the bare minimum permissions a role requires to perform their task.

‍

Oh, and don't forget: it's much more secure to create IAM roles with limited permissions and assign those to users or groups, instead of assigning permissions to users directly. This makes managing permissions much easier.

‍

Mistake #7: Not removing unused roles, users, credentials, etc.

Do you ever get pissed off when someone's desktop is crowded with a bunch of disorganized icons and files, most of which they haven't used in months? (And if you're one of those people, shame on you.)

‍

This is sort of like that. Except it's much worse: when you don't remove unused IAM identities, you're leaving exploitable threat vectors just lying around, waiting to be compromised.

‍

If an IAM user, role, group, permission, or credential hasn't been used for an extended period of time, it's safer to remove it. If an attacker uses an old, forgotten role or credential to log in to your AWS, you'd have no way of knowing, even with monitoring tools.

‍

Take a deeper dive into AWS IAM with our hands-on course! Start learning today.

‍

Mistake #8: Not encrypting secrets with AWS KMS

Secrets are some of the most precious data you're storing in your apps. From credentials and passwords, to sensitive user data, this is information that can't get compromised at any cost. The best way to prevent such a disaster is to use encryption.

‍

AWS Key Management Service (KMS) is the primary service you'll use to create and store cryptographic keys in your AWS environment. It's got numerous functionalities, like creating new encrypted keys, managing and storing them, and even automating the rotation of keys.

‍

One of the most interesting features of KMS is that it integrates with CloudTrail to let you log the use of your cryptographic keys for auditing, regulatory, and compliance needs.

‍

Master secrets management in AWS. Try our hands-on Secrets in AWS course!

‍

Don't let security concerns mess up your holiday plans

AppSecEngineer's suite of courses spans not just AWS security, but DevSecOps, Containers & Kubernetes, Threat Modeling, and more. Every lesson features hands-on labs that help you learn real-world security skills in 1 month.

‍

We've also got Playgrounds, where developers can learn secure coding in their language of choice.

‍

Not to mention, our Challenges are hands-on problem-solving exercises where you find and fix security issues in real-world environments.

‍

Looking to train your team in Application Security? Get in touch with us and we'll give you a demo.

‍

Want to boost your career with Security skills? Unlock all 50+ courses, 700+ labs today.

‍