Controls without any justifications or wrong

[ilanabitbol]

In "All Controls" dashboard, there is a lot of controls without any justification or source like a compliance standard. Some time some of them are false, for instance this one: https://github.com/turbot/steampipe-mod-aws-compliance/blame/295fc3665d69067b7c8584c59473141556c8f0a3/conformance_pack/iam.sp#L15-L21.

It's clear that this statement is false: Based on https://www.tenable.com/policies/[type]/AC_AWS_0427 for instance.

[misraved]

Welcome to Steampipe @ilanabitbol and apologies for the snag!!

As per https://www.tenable.com/policies/%5Btype%5D/AC_AWS_0427, our resource evaluation definitely looks incorrect. We will revisit the source of this control and check if we missed the key point.

Thanks once again for pointing it out 👍.

[ilanabitbol]

Thanks for your feedback! I think there are too many controls in the "All controls" section that are not justified, not well documented or not based on any reference framework.

For instance this control: What benchmark are you basing this on? If it's a " unique “ new control, why not define a community " steampipe " benchmark where new controls could be added on the basis of votes and solid justifications.

[rajlearner17]

@ilanabitbol Thanks for raising this issue.

AWS compliance controls have been added and updated gradually based on multiple sources/feedback/references from time to time. We may have missed updating or taken off some unwanted controls. We rely on the community to contribute and give feedback to bring those changes. Thank you again for indicating this.

For the below control, we had this query designed only to check the Virtual MFA; no reference is available to justify now; however, this control is not using any critical benchmark other than all_controls. The reason for bringing all_controls was to consolidate all unique controls & any orphan controls in one place and gradually update them.

The control below will generate a false-negative for the root user using h/w-based MFA. However, another control exists; iam_root_user_mfa_enabled is used across important benchmarks. This should address the general use of MFA irrespective of h/w or virtual.

Similarly, we have a specific case for checking h/w MFA i.e. iam_root_user_hardware_mfa_enabled

Expected action from us -

• We will decide to take this query off the list, which is only used in all_controls
• iam_root_user_hardware_mfa_enabled will be updated with the correct reason whether using h/w or virtual

-- This goes to alarm even if the h/w MFA is enabled for the root user.

query "iam_root_user_virtual_mfa" {
  sql = <<-EOQ
    select
      'arn:' || s.partition || ':::' || s.account_id as resource,
      case
        when account_mfa_enabled and serial_number is not null then 'ok'
        else 'alarm'
      end status,
      case
        when account_mfa_enabled = false then 'MFA is not enabled for the root user.'
        when serial_number is null then 'MFA is enabled for the root user, but the MFA associated with the root user is a hardware device.'
        else 'Virtual MFA enabled for the root user.'
      end reason
      ${replace(local.common_dimensions_qualifier_global_sql, "__QUALIFIER__", "s.")}
    from
      aws_iam_account_summary as s
      left join aws_iam_virtual_mfa_device on serial_number = 'arn:' || s.partition || ':iam::' || s.account_id || ':mfa/root-account-mfa-device';
  EOQ
}

For your 2nd question, e.g. on this iam_user_access_key_unused_45,

We have provided as many multiple sample queries for users to follow as possible and allow flexibility for them to develop their custom queries; there could be scenarios where it looks similar but with some slight changes, e.g.,

iam_user_access_key_unused_45 >> Checks only the access key use from the credential report iam_user_unused_credentials_45 >> Checks both password and access key from the credential report

HTH :pray: Cheers!!