IAM.sp contains redundant controls

[JeffreyFudge]

IAM.sp contains the following controls related to password policies:

    control.iam_account_password_policy_min_length_14,
    control.iam_account_password_policy_one_lowercase_letter,
    control.iam_account_password_policy_one_number,
    control.iam_account_password_policy_one_symbol,
    control.iam_account_password_policy_one_uppercase_letter,
    control.iam_account_password_policy_reuse_24,
    control.iam_account_password_policy_strong,
    control.iam_account_password_policy_strong_min_length_8,
    control.iam_account_password_policy_strong_min_reuse_24,

The last 3 (strong policy controls) are supersets of the granular control checks listed above them. When run, this causes ambiguous and confusing output due to the mix of granular and summarized checks (and varying minimum length checks, as an example). I see no reason to leave the last three controls in place as they seem to have been superseded by the granular controls.

[rajlearner17]

@JeffreyFudge Thanks for using Steampipe!

I appreciate your raising these concerns, and we are also evaluating the same with our monthly schedules. Here are a few explanations and actions planned

Some of the below controls are very specific to CIS as mentioned below, which will stay based on the individual benchmark requirements

-- control.iam_account_password_policy_min_length_14 >>  Used in CIS, as it's only recommended to check 14 days e.g. cis_v140_1_8
-- control.iam_account_password_policy_one_lowercase_letter, >>  Used in CIS control cis_v120_1_6
-- control.iam_account_password_policy_one_number, >>  Used in CIS control cis_v120_1_8
-- control.iam_account_password_policy_one_symbol,  >>  Used in CIS control cis_v120_1_7
-- control.iam_account_password_policy_one_uppercase_letter, >> Used in CIS control  cis_v120_1_5
-- control.iam_account_password_policy_reuse_24, >> Used in CIS control  cis_v120_1_5

-- control.iam_account_password_policy_strong_min_length_8, >> Used in AWS recommended controls like [foundational_security_iam_7](https://docs.aws.amazon.com/securityhub/latest/userguide/iam-controls.html#iam-7)

-- control.iam_account_password_policy_strong_min_reuse_24, >> This is also used in different benchmarks depending on its requirements (https://docs.aws.amazon.com/config/latest/developerguide/iam-password-policy.html. - This is AWS managed config rule.)

Action item The iam_account_password_policy_strong will be replaced with iam_account_password_policy_strong_min_reuse_24 for the required benchmarks. This should have been replaced in CISA Cyber Essentials, GDPR, ffiec/d_3. New PR will be raised.

We understand your worries about using some of these controls as individual checks when we have a superset single control available e.g. iam_account_password_policy_strong_min_reuse_24. We keep updating this redundancy from time to time in our monthly updates. However, many of these controls are provided as reference queries to use/reuse based on custom needs. At the same time, community users may be using some of these controls as is in the current form using the entire AWS mod; hence, taking off any control requires a more careful decision, and we will definitely consider this in the coming week. At least to streamline the all_controls benchmark, ensure this redundancy can be reduced.

We'll assemble around this issue in the coming week (Jan first week) and decide the course of measures. Happy to discuss further input around it.

[JeffreyFudge]

Hello Raj,

Thank you for the thoughtful and detailed reply, and admittedly this is only an issue with the "all controls" benchmark. I suppose I find it less abstract if variations of password requirements were always handled with discrete controls for each password attribute (as opposed to superset packaging as framework requirements differ). If always done at the most granular level, the control names and output in the results would be more clearly understood (imho). I've attached how the "all controls" dashboard appears, which led to my initial confusion.

I'm not discounting the impact of changes to existing users, as certainly that plays into how this will change, if at all. However, imagine imagine viewing results from "all controls" and seeing this instead:

Minimum password length of 8 - ok
Minimum password length of 10 - alarm

The term "strong configuration" has an almost infinite number of permutations, and as each framework update will likely cause even more variations of the superset packaging, this approach would appear to not scale well over time.

I understand bundling into supersets makes it potentially more convenient within certain frameworks, but you pay the price when utilizing the all controls benchmark because the output is visually confusing. Anyway, some food for thought.

Love the product, and thanks for hearing me out!