Skip to main content

πŸ“ AWS S3 Bucket MFA Delete is not enabled 🟠🟒

  • Contextual name: πŸ“ Bucket MFA Delete is not enabled 🟠🟒
  • ID: /ce/ca/aws/s3/bucket-mfa-delete
  • Located in: πŸ“ AWS S3

Flags​

Our Metadata​

  • Policy Type: BEST_PRACTICE
  • Policy Category:
    • SECURITY

Similar Policies​

Similar Internal Rules​

RulePoliciesFlags
βœ‰οΈ dec-z-bb7312921

Logic​

Internal Notes πŸŸ β€‹

Open File

Notes​

There are different implementations of this policy by different vendors.

The differences:

  • Some only checks if MFA Delete has status enabled and doesn't acknowledge the lifecycle configuration.
  • Others checks if MFA Delete is enabled and lifecycle configuration has status enabled but doesn't take into consideration that if the status is disabled then you still can't enable MFA. You need to remove the lifecycle rules completely in order to be able to activate MFA delete.

Concerns that competitors do not advise:

  • Amazon specifies that versioning is the security best practice but MFA Delete is just another optional layer of security.
  • How do we determine which objects should have MFA delete enabled? It doesn't make sense to activate MFA delete for every object
  • What's a good practice to enable MFA Delete and what's not.
  • This should be a best practice that you can implement for some objects and not a policy which violations you need to resolve

... see more

Description​

Open File

Description​

Amazon S3 provides an MFA Delete feature to add an extra layer of security when deleting objects from your S3 buckets. This feature requires additional authentication via MFA before allowing the deletion of objects, thereby reducing the risk of accidental or unauthorized deletions.

Rationale​

Not all S3 buckets need to have MFA Delete enabled. Typically, you might want to enable MFA Delete for buckets with critical or sensitive objects that require an additional layer of protection.

Consider enabling MFA Delete for buckets with such objects as​
  • Critical Configuration Files
  • Sensitive Customer Data
  • Legal or Compliance Documents
  • Highly Valuable Assets

Buckets with less critical or easily replaceable objects may not need MFA Delete enabled, but this decision should be based on your specific security and compliance requirements.

Impact​

Enabling MFA delete on an S3 bucket could required additional administrator oversight. Enabling MFA delete may impact other services that automate the creation and/or deletion of S3 buckets.

... see more

Remediation​

Open File

Remediation​

Prerequisites​

Required Configuration​
  • Activate an MFA device for the root user.
  • Configure the AWS CLI with the root credentials (access key and secret key)
Important Notes​
  • Only the bucket owner that is logged in as an AWS root account can enable MFA Delete feature.

From Command Line​

Enable MFA Delete​

The following example enables S3 Versioning and MFA delete on a bucket. Replace {{your-bucket-name}} with the actual name of the bucket. Replace {{mfa-device-ARN}} and {{6-digit-mfa-device-code}} with the root account MFA device ARN and authentication code:

aws s3api put-bucket-versioning --bucket {{your-bucket-name}} --versioning-configuration Status=Enabled,MFADelete=Enabled --mfa "{{mfa-device-ARN}} {{6-digit-mfa-device-code}}"
Test MFA Delete​

Ensure that MFA Delete is configured correctly by attempting to delete an object using the AWS CLI. Replace {{object-key}} with the key of the object you want to delete:

aws s3api delete-object --bucket {{your-bucket-name}} --key {{object-key}} --mfa "{{mfa-device-ARN}} {{6-digit-mfa-device-code}}"

... [see more](remediation.md)

policy.yaml​

Open File

Linked Framework Sections​

SectionSub SectionsInternal RulesPoliciesFlags
πŸ’Ό APRA CPG 234 β†’ πŸ’Ό 4 Regulated entities would typically put in place processes to ensure that identities and credentials are issued, managed, verified, revoked and audited for authorised devices, users and software/processes.88
πŸ’Ό APRA CPG 234 β†’ πŸ’Ό 5 The strength of identification and authentication would typically be commensurate with the impact should an identity be falsified. Common techniques for increasing the strength of identification and authentication include the use of strong password techniques (i.e. length, complexity, re-use limitations and frequency of change), utilisation of cryptographic techniques and increasing the number and type of authentication factors used. Authentication factors include something an individual: a. knows - for example, user IDs and passwords; b. has - for example, a security token or other devices in the person’s possession used for the generation of one-time passwords; c. is - for example, retinal scans, hand scans, signature scans, digital signature, voice scans or other biometrics.33
πŸ’Ό APRA CPG 234 β†’ πŸ’Ό 6 The following are examples where increased authentication strength is typically required, given the impact should an identity be falsified: a. administration or other privileged access to sensitive or critical information assets; b. remote access (i.e. via public networks) to sensitive or critical information assets; c. high-risk activities (e.g. third-party fund transfers, creation of new payees)22
πŸ’Ό APRA CPG 234 β†’ πŸ’Ό 44b deletion or corruption of both production and backup data, either through malicious intent, user error or system malfunction;67
πŸ’Ό APRA CPG 234 β†’ πŸ’Ό 45 An understanding of plausible worst case scenarios can help regulated entities identify and implement additional controls to prevent or reduce the impact of such scenarios. One example is malware that infects computers and encrypts data, both on the infected computer and any connected storage, including (corporate) networks and cloud storage. Such attacks reinforce the importance of protecting the backup environment in the event that the production environment is compromised. Common techniques to achieve this include network segmentation, highly restricted and segregated access controls and network traffic flow restrictions.3436
πŸ’Ό APRA CPG 234 β†’ πŸ’Ό j. multi-factor authentication for privileged access, remote access and other high-risk activities;22
πŸ’Ό CIS AWS v1.4.0 β†’ πŸ’Ό 2.1.3 Ensure MFA Delete is enable on S3 buckets11
πŸ’Ό CIS AWS v1.5.0 β†’ πŸ’Ό 2.1.3 Ensure MFA Delete is enabled on S3 buckets - Level 1 (Automated)11
πŸ’Ό CIS AWS v2.0.0 β†’ πŸ’Ό 2.1.2 Ensure MFA Delete is enabled on S3 buckets - Level 2 (Manual)11
πŸ’Ό CIS AWS v3.0.0 β†’ πŸ’Ό 2.1.2 Ensure MFA Delete is enabled on S3 buckets - Level 2 (Manual)11
πŸ’Ό CIS AWS v4.0.0 β†’ πŸ’Ό 2.1.2 Ensure MFA Delete is enabled on S3 buckets (Manual)1
πŸ’Ό CIS AWS v4.0.1 β†’ πŸ’Ό 2.1.2 Ensure MFA Delete is enabled on S3 buckets (Manual)1
πŸ’Ό CIS AWS v5.0.0 β†’ πŸ’Ό 2.1.2 Ensure MFA Delete is enabled on S3 buckets (Manual)1
πŸ’Ό Cloudaware Framework β†’ πŸ’Ό Data Protection and Recovery10
πŸ’Ό FedRAMP High Security Controls β†’ πŸ’Ό AC-7 Unsuccessful Logon Attempts (L)(M)(H)11
πŸ’Ό FedRAMP High Security Controls β†’ πŸ’Ό IA-6 Authentication Feedback (L)(M)(H)11
πŸ’Ό FedRAMP Low Security Controls β†’ πŸ’Ό AC-7 Unsuccessful Logon Attempts (L)(M)(H)1
πŸ’Ό FedRAMP Low Security Controls β†’ πŸ’Ό IA-6 Authentication Feedback (L)(M)(H)1
πŸ’Ό FedRAMP Moderate Security Controls β†’ πŸ’Ό AC-7 Unsuccessful Logon Attempts (L)(M)(H)1
πŸ’Ό FedRAMP Moderate Security Controls β†’ πŸ’Ό IA-6 Authentication Feedback (L)(M)(H)1
πŸ’Ό ISO/IEC 27001:2022 β†’ πŸ’Ό 5.10 Acceptable use of information and other associated assets1114
πŸ’Ό ISO/IEC 27001:2022 β†’ πŸ’Ό 5.15 Access control1416
πŸ’Ό ISO/IEC 27001:2022 β†’ πŸ’Ό 8.2 Privileged access rights77
πŸ’Ό ISO/IEC 27001:2022 β†’ πŸ’Ό 8.3 Information access restriction1011
πŸ’Ό ISO/IEC 27001:2022 β†’ πŸ’Ό 8.4 Access to source code89
πŸ’Ό NIST CSF v1.1 β†’ πŸ’Ό PR.AC-1: Identities and credentials are issued, managed, verified, revoked, and audited for authorized devices, users and processes1922
πŸ’Ό NIST CSF v1.1 β†’ πŸ’Ό PR.AC-6: Identities are proofed and bound to credentials and asserted in interactions48
πŸ’Ό NIST CSF v1.1 β†’ πŸ’Ό PR.AC-7: Users, devices, and other assets are authenticated (e.g., single-factor, multi-factor) commensurate with the risk of the transaction (e.g., individuals' security and privacy risks and other organizational risks)1922
πŸ’Ό NIST CSF v1.1 β†’ πŸ’Ό PR.MA-2: Remote maintenance of organizational assets is approved, logged, and performed in a manner that prevents unauthorized access11
πŸ’Ό NIST CSF v2.0 β†’ πŸ’Ό ID.AM-08: Systems, hardware, software, services, and data are managed throughout their life cycles3
πŸ’Ό NIST CSF v2.0 β†’ πŸ’Ό PR.AA-01: Identities and credentials for authorized users, services, and hardware are managed by the organization23
πŸ’Ό NIST CSF v2.0 β†’ πŸ’Ό PR.AA-02: Identities are proofed and bound to credentials based on the context of interactions8
πŸ’Ό NIST CSF v2.0 β†’ πŸ’Ό PR.AA-03: Users, services, and hardware are authenticated22
πŸ’Ό NIST CSF v2.0 β†’ πŸ’Ό PR.AA-05: Access permissions, entitlements, and authorizations are defined in a policy, managed, enforced, and reviewed, and incorporate the principles of least privilege and separation of duties58
πŸ’Ό NIST SP 800-53 Revision 4 β†’ πŸ’Ό IA-2 IDENTIFICATION AND AUTHENTICATION (ORGANIZATIONAL USERS)1311