Prowler Groups, Checks, and what they mean Part 1
As spoken prior in PROWLING WITH S.A.F.H. (OR THE HANGOVER.) Prowler is heavily based on the CIS benchmarks for AWS. Those benchmarks are broken into a series of groups:
- Check11 to Check122 – From section 1 (Identity and Access Management)
- Check21 to Check29 – From Section 2 (Logging)
- Check31 to Check314 – From Section 3 (Monitoring)
- Check41 to Check46 – From Section 4 (Networking)
- Check71 to Check799 – From the InfoSec Community, GASSP-based checks are specific to the AWS environment.
For general enlightenment, let’s take these groups one to a post, review the check(s), map it to the relevant Benchmark, and discuss those.
Also, as spoken prior, “If your security practitioner makes a suggestion, it is, in fact, a recommendation based on his knowledge, experience, and the standards provided by various standards committees and the infosec community; again, NOT A SUBSTITUTE for advice from a compliance attorney.”
In short, any information offered here must be viewed in the light of OPO, “Other People’s Opinion.” And as such, my opinions are my opinions, not legal advice.
All the legal disclaimers are out of the way; let’s dive into a prowler run.
We will start a prowler run with my default profile, linked to a test account, and specify group 1. This maps to the CIS AWS Foundation benchmark, Identity, and Access Management Recommendations.
I will invoke prowler from the prowler directory of my space heater server with the following command:
./prowler -f 'us-east-1' -g group1
This will start a prowler run limiting it to the us-east-1 region and using only the checks from group1
We have the results as follows:
Color code for results:
- INFO (Information)
- PASS (Recommended value)
- WARNING (Ignored by allowlist)
- FAIL (Fix required)
This report is being generated using credentials below:
AWS-CLI Profile: [default] AWS API Region: [us-east-1] AWS Filter Region: [us-east-1]
AWS Account: [REDACTED] UserId: [REDACTED]
Caller Identity ARN: [arn:aws:iam::REDACTED]
Generating AWS IAM Credential Report... - []
1.1 [check11] Avoid the use of the root account - iam [High]
FAIL! us-east-1: Root user in the account was last accessed 1 day ago
1.2 [check12] Ensure multi-factor authentication (MFA) is enabled for all IAM users that have a console password - iam [High]
PASS! us-east-1: No users found with Password enabled and MFA disabled
1.3 [check13] Ensure credentials unused for 90 days or greater are disabled - iam [Medium]
PASS! us-east-1: User XXXX has logged into the console in the past 90 days
PASS! us-east-1: User XXXX has used access key 1 in the past 90 days
PASS! us-east-1: No users found with access key 2 enabled
1.4 [check14] Ensure access keys are rotated every 90 days or less - iam [Medium]
PASS! us-east-1: No users with access key 1 older than 90 days
PASS! us-east-1: No users with access key 2
1.5 [check15] Ensure IAM password policy requires at least one uppercase letter - iam [Medium]
PASS! us-east-1: Password Policy requires upper case
1.6 [check16] Ensure IAM password policy require at least one lowercase letter - iam [Medium]
PASS! us-east-1: Password Policy requires lower case
1.7 [check17] Ensure IAM password policy require at least one symbol - iam [Medium]
PASS! us-east-1: Password Policy requires symbol
1.8 [check18] Ensure IAM password policy require at least one number - iam [Medium]
PASS! us-east-1: Password Policy requires number
1.9 [check19] Ensure IAM password policy requires minimum length of 14 or greater - iam [Medium]
PASS! us-east-1: Password Policy requires more than 13 characters
1.10 [check110] Ensure IAM password policy prevents password reuse: 24 or greater - iam [Medium]
PASS! us-east-1: Password Policy limits reuse
1.11 [check111] Ensure IAM password policy expires passwords within 90 days or less - iam [Medium]
PASS! us-east-1: Password expiration is set
1.12 [check112] Ensure no root account access key exists - iam [Critical]
PASS! us-east-1: No access key 1 found for root
PASS! us-east-1: No access key 2 found for root
1.13 [check113] Ensure MFA is enabled for the root account - iam [Critical]
PASS! us-east-1: Virtual MFA is enabled for root
1.14 [check114] Ensure hardware MFA is enabled for the root account - iam [Critical]
FAIL! us-east-1: Only Virtual MFA is enabled for root
1.15 [check115] Ensure security questions are registered in the AWS account - support [Medium]
INFO! us-east-1: No command available for check 1.15. Login to the AWS Console as root & click on the Account. Name -> My Account -> Configure Security Challenge Questions.
1.16 [check116] Ensure IAM policies are attached only to groups or roles - iam [Low]
PASS! us-east-1: No policies attached to user crawls
1.17 [check117] Maintain current contact details - support [Medium]
PASS! us-east-1: Account has contact information. Perhaps check for freshness of these details.
1.18 [check118] Ensure security contact information is registered - support [Medium]
FAIL! us-east-1: Account has not security contact information, or it was unable to capture.
1.19 [check119] Ensure IAM instance roles are used for AWS resource access from instances - ec2 [Medium]
PASS! us-east-1: Instance REDACTED associated with role REDACTED
1.20 [check120] Ensure a support role has been created to manage incidents with AWS Support - iam [Medium]
FAIL! us-east-1: Support Policy not applied to any Role
1.21 [check121] Do not setup access keys during initial user setup for all IAM users that have a console password - iam [Medium]
PASS! us-east-1: No users found with access key 1 never used
PASS! us-east-1: No users found with access key 2 never used
1.22 [check122] Ensure IAM policies that allow full "*:*" administrative privileges are not created - iam [Medium]
PASS! us-east-1: Policy REDACTED that does not allow full "*:*" administrative privileges
PASS! us-east-1: Policy REDACTED that does not allow full "*:*" administrative privileges
PASS! us-east-1: Policy REDACTED that does not allow full "*:*" administrative privilegesThe color code is:
- Yellow – Informational, One may want to review these items
- Green – Pass, we did something right
- Orange – Warning, Not seen often, but well worth reviewing
- Red – Fail, we did something wrong.
An AWS Credential report is generated, and checks are run against this.
Our first check, 1.1 (lines 14, 15), shows a failure; the root user account was accessed in the last day.
From the CIS Benchmark:
It so happens that I had to reset a password for my only admin-level user. It is suggested that an administrators group be created and individual IAM users attached to it. Use of the root-level account is discouraged.
The second check, 1.2 (lines 16, 17), shows that we have complied with the recommendations for all console access accounts to have MFA enabled.
From the CIS Benchmark:
Our check 1.3 (lines 18 to 21) demonstrates that we do not have any stale users or stale access keys. (Access Keys and Secret Access Keys provide programmatic access to the AWS API to automate tasks without constantly clicking on a web console.)
From the CIS Benchmark:
The check at 1.4 (lines 22-24) Ensure access keys are rotated every 90 days or less (Scored), which is very similar to password rotation requirements but for direct programmatic access to the AWS API. This access is quite powerful, and access keys get stolen; it is best to rotate them regularly. The under-ware rules apply here. Only use your own, Don’t share, and change them regularly.
Checks 1.5 to 1.11 (lines 25 – 38) deal with password length, complexity, and rotation. Therefore, I’ll not include the 12 pages of discussion from the CIS Benchmarks. Instead, I will include one graphic that explains the need for password length, complexity, and rotation.
If one used a password 14 characters in length and included numbers, uppercase letters, lowercase letters, and symbols, it would take longer to brute force than the password rotation would allow. By a lengthy amount of time.
Check 112 (lines 39-42) demonstrates that the Root account does not have programmatic access; just as we should not use the root account for daily operations, it should NEVER be used for programmatic access.
From the CIS Benchmark:
Checks 113 and 114 (lines 42-45) provide evidence that an MFA (virtual) is in place for the root account. However, check 114 is more problematic as CIS Standards recommend using a hardware token for MFA.
It is my experience that this may cause issues for access whence required. (Tokens get lost, batteries in tokens expire, and the token itself may expire.) It is up to the user to determine if this will be followed. Even the Benchmark notes the logistical issues in the recommendation.
This is NOT TO BE misunderstood that MFA is not required for the root account.
From the CIS Benchmark:
And
Check 115 (lines 46 and 47) Is not automatable. Instead, it determines if the account has set security validation questions with Amazon. The creation of these is one of the few ROOT Level functions that can only be performed at the AWS Management Console.
From the CIS Benchmark: ( Full Benchmark quotation)
Check 116 (lines 48, 49) This reviews each user for directly attached permissions or in-line policies. The complexity of user permission management is reduced by establishing groups or roles and assigning them to a user.
From the CIS Benchmark:
Check 117 (lines 50,51). Contact information for the AWS account should be provided and should be reviewed regularly. There is the possibility that the AWS Security or Operations team will need to reach someone in control of the AWS Account.
From the CIS Benchmark:
Check 118 (Lines 52 and 53) Similar to check 117, contact for security events should be provided and checked regularly for correctness. This contact may be the same as 117 or different.
From the CIS Benchmark:
Check 119 (Lines 54 and 55) is very similar to check 116, but for actual AWS resources. Management of access and permissions is best done with roles so that permission sprawl or credential exposure does not occur.
From the CIS Benchmark:
Check 120 (Lines 56 and 57) is quite similar to checks 117 and 118; this will enable a user or users to open AWS Support Cases.
From the CIS Benchmark:
From the CIS Benchmark:
Check 122 (Lines 61 – 64) This check reviews IAM policies that may be overly permissive. These can lead to account compromise.
From the CIS Benchmark:
General Notes:
Whilst these seem “Common Sense” whence explained, it has been my experience that many of these items are not implemented. This seems to occur most frequently in the born-in-cloud start-up community, where the drive is to launch a product.
Also, in my experience, there will be some pushback on the recommendations, hence my direct quotation of the benchmarks. (I.E. Don’t take my word for it, read the benchmark for yourself.)
I will specifically acknowledge The Center for Internet Security and urge the reader to visit their site and support them as the reader can. Their works and benchmarks have become the foundation for many of the existing governmental and commercial standards in place today.
