Check ID32="3.2,3.02" needs improvement

[GaboP87]

Hi,

From the AWS_CIS_Foundations_Benchmark PDF file (https://d0.awsstatic.com/whitepapers/compliance/AWS_CIS_Foundations_Benchmark.pdf), for the check 3.2 (page 91), it is stated that it would be necessary to check for this Filter Pattern of the specified Metric:

"filterPattern": "{ ($.eventName = "ConsoleLogin") && ($.additionalEventData.MFAUsed != "Yes") }"

Since it is not possible to check only for this because it would involve ConsoleLogin for IAM Federated Users as well (assumed roles for the federated groups in AD), and it is not possible to configure MFA for federated users (IAM Roles) as a native AWS Solution, I created the following Filter Pattern which covers the ConsoleLogin API call with success for any generic IAM User, as well as for the root user of the AWS Account:

"filterPattern": "{ ($.userIdentity.type= IAMUser || $.userIdentity.type= Root) && ($.responseElements.ConsoleLogin= Success) && ($.additionalEventData.MFAUsed != "Yes") }"

This works well from any CIS Benchmark Security Requirement. However, from a quick review of the Prowler script (Line 1058), I found the following Regex checking for:

'userIdentity.sessionContext.attributes.mfaAuthenticated.*true'

This will clearly result in an error. It checks for any Metric which looks for Logs containing the sessionContext attribute. It does not appear whenever an IAM User or the root account signs successfully to the console without MFA. It will check for all the API Calls with that parameter in the Log stream. Examples of these API Calls:

• ListInstanceProfiles
• DescribeStaleSecurityGroups
• DescribeAddresses
• etc.

And neither of the API Calls containing the sessionContext parameter have ConsoleLogin as an eventName parameter.

Can you help me with this please?

Cheers,
Gabriel

[toniblyx]

Thanks @GaboP87, do you mean that changing L 1058 with your suggestion works fine?

[GaboP87]

Hi @toniblyx, no. I mean that the Regex that is being used in the Prowler script is the wrong one in order to correctly check for a successful login without MFA. If you check the AWS_CIS_Foundations_Benchmark PDF file, in page 91 you can read the exact description of the requirement to be fulfilled in this case.

Now, being the requirement too generic, and being currently three ways to login into an AWS Console (root account, IAM User, assumed IAM Role), it is necessary to specify different checks here:

• login with the Root Account without MFA
• login with an IAM User without MFA
• login with a federated user by assuming an IAM Role without MFA
  Unfortunately, for the last case there is no native AWS Solution in order to implement MFA and so the check is restricted only to IAM Users and the Root AWS Account. It is necessary to check for:
  ( $.userIdentity.type= IAMUser || $.userIdentity.type= Root )

The login needs to be successful in order to track this event. For failed logins there is already a CloudWatch Metric and associated Alarm that takes care of it. It is necessary then to check for:
( $.responseElements.ConsoleLogin= Success )

We need to track all those successful logins from any IAM User of the Root Account which did not use MFA. for this we need to check for: ( $.additionalEventData.MFAUsed != "Yes" )

Finally, from the Prowler script, it will be great to check for different Regex patterns for the two Filter Patterns that might be together, or separated depending on how the Metrics and Alarms are configured:

• Together: for IAM Users and the Root Account:
  | grep -E 'userIdentity.type.*IAMUser.*Root.*Success|additionalEventData.MFAUsed.*Yes'
• Separated: for the IAM Users:
  | grep -E 'userIdentity.type.*IAMUser.*Success|additionalEventData.MFAUsed.*Yes'
  for the Root Account:
  | grep -E 'userIdentity.type.*Root.*Success|additionalEventData.MFAUsed.*Yes'
  In my personal opinion, it would be better to separate the two checks. I leave it to you, whatever you prefer is great, the important thing is to have a consistent assessment when running the Prowler script.

Let me know if you understood what I mean with this.

Cheers,
Gabriel

[toniblyx]

Thanks @GaboP87 I haven't forgot you, just a bit busy these days. I'll get back to this asap.

[toniblyx]

Hi @GaboP87, I think I've fixed it. This is the trick:

aws logs describe-metric-filters --log-group-name CloudTrail/DefaultLogGroup --profile xxxx --region us-east-1 --query 'metricFilters' |grep filterPattern|awk '/.userIdentity.type/&&/IAMUser/||/root/&&/.responseElements.ConsoleLogin/&&/.additionalEventData.MFAUsed/&&/Yes/'

[toniblyx]

Please, feel free to open this case again if doesn't work for you.