Prowling with S.A.F.H. (or The Hangover.)

Recently I had dinner and drinks with an old friend and long-time partner in chaos; he has since semi-retired to the northlands but pops by once in a while to share his knowledge and twisted sense of humor.

During the gastro-gluttony, he mentioned an open-source package called prowler to review basic Amazon Web Services account security and compare it to various official and community standards. As he recommends it, I suspect it is worth a closer look. But, as usual, I find anything S.A.F.H. mentions is an attractive rabbit hole that will consume many hours, many brain cells, and a fair amount of high-quality bourbon.

From the prowler page on git-hub.

Prowler is an Open Source security tool to perform AWS security best practices assessments, audits, incident response, continuous monitoring, hardening and forensics readiness. It contains more than 240 controls covering CIS, PCI-DSS, ISO27001, GDPR, HIPAA, FFIEC, SOC2, AWS FTR, ENS and custom security frameworks.

From his discussion, it was recommended that this be run from an AWS EC2 instance with an appropriate profile attached or from a local server using the AWS CLI and the suitable profile’s access keys and secret access key.

I have a server currently being used as a space heater in my office, so this would be an excellent place to start. I’ll not bore the reader to tears with the installation of Ubuntu 22.10, AWS CLI v2, creation of access keys, etc., etc., but will dive directly into the installation of the prowler software and its operation.

We will assume that one has logged into the previously mentioned machine and become the superuser. From time to time, we will discover additional required packages and note their installation.

sudo apt update
sudo apt install python3 python3-pip jq git zip
pip install detect-secrets==1.0.3
curl "https://awscli.amazonaws.com/awscli-exe-linux-x86_64.zip" -o "awscliv2.zip"
unzip awscliv2.zip
sudo ./aws/install
aws configure
git clone https://github.com/prowler-cloud/prowler

I’ll divert from the git-hub page and note the following concerning the detect secrets package: the detect-secrets package performs very poorly, both in actual execution and the simple fact that any data in a code base will spawn a positive, true or false. That said, it is the reader’s decision to use this.

To run a basic prowler scan with the default AWS profile:

cd prowler
./prowler

This will result in the following header:

When we see that the AWS IAM Credential Report is being generated, we can be sure that we have all the bits and pieces in the right places and can let this run more automatedly.

./prowler -p <PROFILE> -q -E extra760,extra759 -f <REGION> -M csv

This will run all checks using the profile specified to the default profile; if not specified, it will EXCLUDE extra760 and extra759 checks (the detect-secrets checks spoken about prior) and will save all FAILED checks and their respective data into a .csv file located in the prowler/output directory tagged with the AWS account number and execution time. One suspects that a spreadsheet superhero could use repeated, regularly scheduled runs to provide evidence to an auditor that security remediation is ongoing.

Whilst the prowler is scanning and comparing, a short sharp discussion on standards and scoring is in order.

1. As a security practitioner, one of the most asked questions is, “Why did you make this determination?” and frankly, the answer is, “I DID NOT MAKE THAT DETERMINATION. The infosec community and the standards committees set those standards and determine if you comply.”
2. The standards are the standards, either you comply or not. The scoring a tool uses when the tool provides scoring comes from the infosec community, the standards committee, and the people who wrote the tool. Arguing the scores with the security practitioner does no good.
3. Scoring, recommendations, and standards are SUGGESTED guidelines; they are NOT A SUBSTITUTE for advice from a compliance attorney.
4. 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.

Our power run has saved its results into the output directory, so it is time to take an overview of the checks. A number of these are based on the CIS AWS Foundations Benchmark; others are based on infosec community input provided by the RFC process. (Bluntly, the RFC process is likened to a medieval mele, with the last man standing as the winner.)

• 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 and specific to the AWS environment.

Do note we have not touched, Hipaa, GDPR, PCI-DSS, etc. Those are highly regulated arenas and, as such, well out of the scope of a document such as this.

I will note the following from the Prower Git-Hub Page.

I find this specific group is rather redundant whence compared to the basic prowler review done prior. I’ve included this for reference if one only wants a technical review.

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

In subsequent posts, I will review each of these sections, discuss the basic reasoning for these, and review remediation options. 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.”