debifrank
commented
1 month ago For lower tier assurance levels, I see the value in keeping this as is for the instances where we do observe a new user with an auto-provisioned access key. For higher assurances, I think it's reasonable to request a more thorough response from the IAM admin for what their new user provisioning process looks like.
Stale or unused access keys seems like a different issue to me relating more to existing key/identity management rather than the organization's default approach to new user provisioning.
Cloud Profile 2.7.2 (https://github.com/appdefensealliance/ASA-WG/blob/main/Cloud%20App%20and%20Config%20Profile/Cloud%20App%20and%20Config%20Test%20Guide.md#272-do-not-setup-access-keys-during-initial-user-setup-for-all-iam-users-that-have-a-console-password) requires that account administrators not assign both Console and API credentials to IAM Users at creation. This seems like a reasonable suggestion, but it's hard to enforce. The AWS Console verification procedure given here is to compare each User's creation time to the creation times of its access keys. That will only work if those access keys have never been rotated since creation. We also require access keys to be rotated every 90 days or less (Cloud Profile 2.8.4 "Ensure access keys are rotated every 90 days or less"), so this check is only meaningful within 90 days of User creation. If the target account's admins routinely violate this requirement but haven't created a new User within 90 days, then this check will pass and the assessor has no way to know that the requirement is being violated.
Further, if a User is created without a Console password but with an access key, and a Console password is later assigned to this User, then the given procedure with flag the user. However, it's unclear if this was intentional.
Additionally, the only way to address a failure of this check is to either rotate the API credentials of the affected Users or to revoke their Console credentials. That will make this check pass but has nothing to do with the underlying problem.
Basically, this requirement cannot be verified with information that's available within the AWS account itself (well, the information might be in CloudTrail logs but that would be a pain to retrieve and we don't require accounts to keep such logs indefinitely). The only way to verify it is to talk to the account's admins and find out what their policies and procedures are. Since everything else in ADA-CP is intended for mostly-automated verification, perhaps we should omit this one.
The command-line investigation and verification sections are very different from the description and Console investigation: rather than looking for access keys created at User creation, they look for access keys that have never been used. Consequently, it's not even clear what the intention of this check is. This version, at least, is well defined. So maybe we should rewrite the title, description, and Console investigation procedure to match the CLI investigation and verification sections?
If we're going to interpret this as being about unused access keys, then I propose that we disregard Console passwords entirely and just check for Users with unused access keys.