Skip to main content

More Info:

Root Account Usage should be monitored using CloudWatch alarms.

Risk Level

High

Address

Security

Compliance Standards

  • APRA CPS 234 (Australia)
  • AWS Startup Security Baseline
  • AWS Well Architected Framework
  • BSI C5 (Germany)
  • Brazil LGPD
  • CCPA / CPRA (California)
  • CIS AWS
  • CIS Critical Security Controls v8
  • CMMC 2.0
  • CSA Cloud Controls Matrix v4
  • Cloudanix Best Practice
  • DPDPA
  • Digital Operational Resilience Act (EU)
  • Essential 8
  • HIPAA
  • HITRUST CSF
  • ISO 27001
  • ISO/IEC 27017
  • ISO/IEC 27018
  • ISO/IEC 27701
  • KSA PDPL
  • MAS Technology Risk Management (Singapore)
  • MITRE ATT&CK (Cloud)
  • NIS2 Directive
  • NIST
  • NIST CSF
  • NIST SP 800-171
  • NYDFS 23 NYCRR 500
  • PCI
  • SOC2
  • SWIFT Customer Security Controls Framework
  • Sarbanes-Oxley IT General Controls
  • UK NCSC Cyber Assessment Framework

Triage and Remediation

Remediation

Using Console

The Root Account Usage Alarm is an AWS Config Rule that checks whether the root account of your AWS account has been used within the last 90 days. If it has been used, it triggers an alarm. To remediate this issue, you can follow the below steps:
  1. Log in to the AWS Management Console.
  2. Go to the AWS Config service.
  3. Click on the Rules tab.
  4. Search for the Root Account Usage rule and click on it.
  5. Click on the Remediation action dropdown and select the “Remediate” option.
  6. In the Remediation action page, select the “Disable root user access keys” option.
  7. Click on the “Create remediation exception” checkbox.
  8. Click on the “Remediate” button to remediate the issue.
This will disable the root user access keys, which will prevent the root account from being used. The remediation exception will ensure that the rule does not trigger again for the same issue.

The Root Account Usage Alarm is triggered when the root account is used to perform any actions in AWS. This is a security risk as the root account has unrestricted access to all resources in the account. To remediate this misconfiguration, follow these steps:
  1. Create a new IAM user with administrative privileges.
    • Use the AWS CLI command aws iam create-user to create a new user.
    • Use the aws iam create-access-key command to generate an access key and secret key for the user.
    • Use the aws iam attach-user-policy command to attach the AdministratorAccess policy to the user. This will give the user full administrative privileges.
  2. Enable multi-factor authentication (MFA) for the root account.
    • Use the aws iam create-virtual-mfa-device command to create a virtual MFA device.
    • Use the aws iam enable-mfa-device command to enable MFA for the root account.
  3. Remove the access keys for the root account.
    • Use the aws iam delete-access-key command to delete the access keys for the root account.
  4. Create an AWS CloudWatch alarm to monitor root account usage.
    • Use the AWS CLI command aws cloudwatch put-metric-alarm to create an alarm that will trigger if the root account is used to perform any actions in AWS.
By following these steps, you will have created a new IAM user with administrative privileges, enabled MFA for the root account, removed the access keys for the root account, and created an alarm to monitor root account usage. This will help to secure your AWS account and reduce the risk of unauthorized access.
The Root Account Usage Alarm is an AWS CloudWatch alarm that triggers when the root account is used to sign in to the AWS Management Console. This is considered a security risk, as the root account has full access to all AWS resources and should be used only for administrative tasks that cannot be performed by other IAM users.
  • Replace <SNS topic ARN> with the ARN of the SNS topic where you want to receive alarm notifications.
Ensure that you have the necessary permissions to create and modify CloudWatch alarms using the AWS CLI or Python script.
This creates a new monitoring setup and assumes CloudTrail is already delivering logs to the specified CloudWatch Logs log group. No existing resources are forced to be replaced; all resources above are new creations. After terraform apply, the email recipient must manually confirm the SNS subscription from the AWS email.Verification: terraform plan should show 4 resources to add (aws_sns_topic, aws_sns_topic_subscription, aws_cloudwatch_log_metric_filter, aws_cloudwatch_metric_alarm) and 0 to change/destroy.

Additional Reading: