Prowler Groups, Checks, and what they mean, Part 2

by Posted on

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 2. This maps to the CIS AWS Foundation benchmark, Logging.

I will invoke prowler from the prowler directory of my space heater server with the following command:

./prowler -g group2 -f "us-east-1"

This will start a prowler run, limiting it to the us-east-1 region and using only the checks from group 2.

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]

2.1 [check21] Ensure CloudTrail is enabled in all regions - cloudtrail [High]
       PASS! us-east-1: Trail crawls-c5trail is multiregion configured from region us-east-1 and it is logging
2.2 [check22] Ensure CloudTrail log file validation is enabled - cloudtrail [Medium]
       PASS! us-east-1: Multiregion trail crawls-c5trail configured from region us-east-1 log file validation enabled
2.3 [check23] Ensure the S3 bucket CloudTrail logs to is not publicly accessible - cloudtrail [Critical]
       PASS! us-east-1: Trail crawls-c5trail with home region us-east-1 S3 logging bucket c4trail-crawls is not publicly accessible
2.4 [check24] Ensure CloudTrail trails are integrated with CloudWatch Logs - cloudtrail [Low]
       PASS! us-east-1: crawls-c5trail trail has been logging during the last 24h
2.5 [check25] Ensure AWS Config is enabled in all regions - configservice [Medium]
       FAIL! us-east-1: AWS Config recorder disabled
2.6 [check26] Ensure S3 bucket access logging is enabled on the CloudTrail S3 bucket - s3 [Medium]
       PASS! us-east-1: Trail crawls-c5trail S3 bucket access logging is enabled for c4trail-crawls
2.7 [check27] Ensure CloudTrail logs are encrypted at rest using KMS CMKs - cloudtrail [Medium]
       PASS! us-east-1: Trail crawls-c5trail has encryption enabled
2.8 [check28] Ensure rotation for customer created KMS CMKs is enabled - kms [Medium]
        PASS! us-east-1: Key REDACTED automatic rotation of the key material is enabled
2.9 [check29] Ensure VPC Flow Logging is Enabled in all VPCs - vpc [Medium]
       PASS! us-east-1: VPC REDACTED VPCFlowLog is enabled

As spoken in my post, C1 – BASIC AWS MONITORING Cloudtrails is the primary data source for tracking all API activity within an AWS account. As such, the CIS standards have many recommendations around CloudTrails and CloudWatch logging. These are laid out in Chapter 2 of the CIS Benchmark and are tested in group 2 of the prowler checks.

Let us begin the review of this prowler run.

Check 21 (lines 13 and 14) Cloudtrail is enabled and logs the specified API activity in all regions. The AWS Tutorial will assist you if this is not set up in your account.

From the CIS Benchmark:

Check 22 (lines 15 and 16) Refers to a validation cross-check of the log data, so that spurious data can not be inserted or existing data modified. (We want to trust that the logs are, in fact, logs, not lies.)

From the CIS Benchmark:

Check 23 (Lines 17 and 18). CloudTrail logs should be written to an S3 bucket as a standard for archival and analysis. Said S3 bucket should comply with the accepted security recommendations for S3 Buckets:
  • The bucket should not be publically accessible. (this check)
  • The bucket should be encrypted (Check 27)
  • Access to the bucket should be logged (Check 26)

These requirements and checks will be seen multiple times in these missives on prowler and CIS and repeated many times in other posts. It should be automatic that creating an S3 bucket will generate the application of the Public Access NACLs, encryption with at least AWS S3-SSE, and that server (bucket) and object access are logged to a central bucket for the account.

Appending the relevant quotes from the CIS Benchmark:

Check 24 (lines 19 and 20). Integrating Cloudtrails with Cloudwatch allows the inspection of events within the Cloudtrails data flow and the ability to spawn actions when a specific set of conditions occurs. This is the basis for almost all SIEM tools. For example, see my post on AWS Event Monitoring, “In the Beginning…”

From the CIS Benchmarks:

Check 25 (lines 21 and 22) AWS Config continually assesses, audits, and evaluates the configurations and relationships of your resources. This tool finds misconfiguration, configuration drift, and malicious configuration changes. It interacts with other tools mentioned, CloudWatch, S3, and SNS.

From the CIS Benchmark:

Check 28 (lines 27 and 28) Rotation of Customer Managed Keys. As these keys are used to encrypt keys, rotation is “key.” The complex task of decrypting data with the old key and encrypting data with the new key is automated by enabling automatic rotation. It happens seamlessly and automatically versus doing this manually. (Anything done manually will either be forgotten or performed incorrectly. Removing human error is always a good thing.)

From the CIS Benchmark:

Check 29 (lines 29 and 30) VPC Flow Logs is a feature that enables you to capture information about the IP traffic going to and from network interfaces in your VPC. Flow log data can be published to the following locations: Amazon CloudWatch Logs, Amazon S3, or Amazon Kinesis Data Firehose.  I differ from the CIS recommendations because I capture ALL traffic, not just rejects. In addition, the amount of forensic data available in the traffic patterns is rich and can assist not just the security team but the operations and development teams. Amazon provides an extensive knowledge base on flow logs, and it is worth the read.

From the CIS Benchmark:

General Notes:

While 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 yourself.)

I will specifically acknowledge The Center for Internet Security and urge the reader to visit their site and support them as they can. Their works and benchmarks have become the foundation for many of the existing governmental and commercial standards in place today.

Published by crawls