Common AWS Security Event Root Causes – Notes – Part #1

Last week I attended an interesting webinar with an engineer from the AWS Customer Incident Response team talk about the most common AWS Security Incident Root Causes. What was fascinating, to me anyway, is that the destructive power of these root causes can be minimized by following standard security best practices. Without further ado, are the six most common AWS Security Event Root Causes to be covered in 3 parts:

1. Unintended disclosure of security credentials and secrets
2. Customer does not ensure the complete accuracy of their AWS account information
3. Insecure AWS resource configuration
4. Inactive response to GuardDuty and other detective controls and alerts
5. Lack of continuous vulnerability management
6. Unmanaged application software security

#1 – Unintended disclosure of security credentials and secrets

Code is everywhere…and very often easily accessible. And as we use code to support multi-account, multi-region, multi-service AWS environments, there will be times when credentials are needed within the code in order to perform a specific function within a specific account or with a specific service. As you are building your code, to support ease of testing, it may be tempting to place the credentials you need directly in the code. After the testing is complete, you’ll take them out, put the credentials in a proper secrets manager, and then configure the code to contact the required vault when needed. But we can easily be overwhelmed as there are so many projects, tickets, tasks, kanban boards, school activities, books to read, errands to run that we may forget to fully validate our code with a security mindset. It works, we upload, we move on, not realizing the potential scope of our negligence.

This can lead to:

• Data theft and destruction
• Hostile takeover of your AWS account(s) and/or destruction of your resource(s)
• Could lead to an abnormal use of those credentials – Do you now see resources being created that have no business even existing?
• You may even get a notice from the AWS Trust and Safety team that your credentials have been compromised

Ways to Detect the Issue:

• Implement application security scanning for static secrets in source code repositories
  • You can use the following links for ideas if you’re looking for some help in this area
    • https://aws.amazon.com/blogs/publicsector/episode-3-building-secure-code/
    • https://geekflare.com/github-credentials-scanner/
• Use CloudTrail and Amazon GuardDuty to investigate identity behavioral changes
• Use CloudWatch Billing Alarms to be alerted to changes in estimated charges
  • Look at your bill, determine an expected monthly spend, and then set a billing alarm that corresponds to your alarm threshold.
• Monitor for AWS notifications sent to an AWS account contact(s)

Prevention:

• Use temporary access over static credentials and keys
• Enable MFA
• Ensure your are following the principle of least privilege access
• Use AWS Secrets Manager (or the vault of your choice) to store credentials needed by your code

#2 – Customer does not ensure the complete accuracy of their AWS account information

In the event that an account is compromised, you will find that account information matters when attempted to regain access to an account. To that end, AWS encourages its customers to ensure their alternate contact information is filled out.

Alternate contacts provide a means for AWS to contact additional people and/or teams concerning account issues if the primary contact for the account is unavailable. As with AWS accounts, an alternate contact does not have to be a specific person but can be an email distribution list should you have teams that are responsible for managing billing, operations and security related issues. In the absence of alternate account information, AWS may be unable to determine who the true account holder should an AWS account be subject to a hostile takeover.

There are three types of alternate contacts:

• Billing
  • will be informed when monthly invoice is available or when payment information needs to be updated
• Operations
  • receives an operations notifications, such as when services will be unavailable
• Security
  • receives notifications from the AWS Security, AWS Trust and Safety, or AWS service teams which may include security issues or abusive or fraudulent activities within an AWS account(s)

To my knowledge, there is no way to set alternate contacts through the CLI or API so you must edit this information through the AWS management console. While your in the console setting your alternate contacts, you’ll also see that you can configure security challenge questions to add an additional layer of security to your account.

Post 1 Wrap-up

That will wrap up post #1. On the next post, we’ll cover items #3 and #4, Insecure AWS resource configuration and Inactive response to GuardDuty and other detective controls and alerts. In the interim, here’s a link to an AWS support article, “What do I do if I notice unauthorized activity in my AWS account?” to reinforce some AWS account basics.