Prerequisites

• Our first Prowler lab.

The Lesson

In our last lab we set up our environment to run the Open Source version of Prowler from our SecurityAudit account. We configured it to use an External ID to prevent the confused deputy attack when it assumes our cross account role to run scans.

Now it’s time to learn a little more about CSPM, it’s big brother CNAPP, and why these tools are so important that they are one of the first things I install when I set up a new (non-lab) AWS organization.

CSPM Capabilities

I’ll be honest, I kind of hate the name “Cloud Security Posture Management”. Like, who cares if my cloud is slouching in its chair? But I also have to admit it makes sense. We can’t call these cloud vulnerability scanners because they aren’t necessarily vulnerabilities, they are just things configured in a way that maybe in the right context could be useful to an attacker. These aren’t really vulnerabilities in the traditional sense because they are allowed configurations, just ones that could be problematic. We need public S3 buckets, but a public bucket might also be bad if we didn’t actually want that particular bucket public.

When I first started in cloud we had to figure all this out ourselves by hand. I quickly moved from doing everything in the console to building my own tools. Then I found Prowler (which we installed last week) and swapped over. Tony kept Prowler up to date with great coverage. It was originally a really complicated bash script that used the AWS CLI!

Obviously everyone had this problem, and thus vendors were born (including mine, although we had a bit of a different focus). Over time these tools consolidated to a core feature set and eventually Gartner caught up and branded the category “CSPM”. At their simplest, modern CSPM tools:

• Connect to a cloud account and read the configuration of the services

• Identify misconfigurations (based on their own list and public standards)

• Rate the misconfiguration severity

• Generate reports

Practically speaking, modern tools all have additional features:

• They run centrally or as a SaaS platform and can assess large multi-account and multi-cloud deployments

• Store all the configuration information in their own internal database, providing customers a full inventory of what is running

• Include an extensive security and compliance database to assess against multiple standards

• Offer extensive complex analysis, such as identifying IAM misconfigurations that could lead to privilege escalation

• Support visualizations of relationships, such as showing the security groups and IAM roles associated with an instance (often called a security graph)

• Offer alerting and complex reporting

It’s really the scale and deep multi-cloud support that sets these tools apart from our earlier ones. But there’s more you might find:

• Real time inventory and assessments (most tools are time based, and some only update daily)

• Correlation with CloudTrail and other logs (e.g. identify who caused a misconfiguration)

• Advanced security graphs that identify potential attack sequences

• And more!

From CSPM to CNAPP

CSPM is the foundation, helping you visualize and manage your cloud “posture” (configuration). They’ve become essential for managing security and compliance, and every major CSP has one built in (for a fee).

Yeah, you’d think they would include a critical security capability in your subscription, but nope. On the upside, third-party tools historically have done a much better job.

While CSPM focuses on core security posture, another tool started developing in parallel. Cloud Workload Protection Platforms (CWPP… blame Gartner not me) actually ARE vulnerability scanners- for instances, containers, and even serverless functions. “Wait” you ask, “didn’t we already have vulnerability scanners for operating systems and stuff?”.

Why yes we did! And they royally sucked for cloud! Those vendors were too fat and happy and asked us to do painful things like open up our security groups for scans, or install agents in containers that… really don’t run well in containers. CWPP products made up cool tricks like scanning snapshots and images so they didn’t have to muck with running things, or build better agents.

Anyway, as you might imagine CWPP started showing up in CSPM tools, or they were bought, or they bought the other guys, or all of the above. And then vendors started adding or buying up features to scan Infrastructure as Code, assess APIs, perform Cloud Detection and Response, focus on identities (a category called Cloud Identity and Entitlement Management (CIEM) because WE JUST CAN’T HELP OURSELVES WITH THESE NAMES AND OH PLEASE MAKE IT STOP!!!!

Anyway, that’s Cloud Native Application Protection Platform (CNAPP). It started as CSPM+CWPP and now includes whatever the vendor can buy or copy from someone else. This isn’t actually a criticism, just the reality that when you see CNAPP it most definitely will include CSPM and workload protection, and might include a LOT of other things you may or may not need depending on who you are and what you are doing.

Why I subjected you to this painful history lesson

My goal with CloudSLAW is to provide you deep, practical knowledge to work as a cloud security professional. Although this lab is over a year into the program, CSPM/CNAPP will be one of the first tools you likely touch if you get a cloud security job. It’s important to know what they are and how they work, which is why we are running through this series and you will get hands-on with multiple different types of tools.

Today is a very basic deployment of Prowler, which was the first Open Source CSPM available, long before anyone put those four words together. Prowler also has a commercial version and can do a lot more than how we are going to use it.

This week we will keep it simple. Last week you scanned your local account, and this week we will use our cross-account role to scan our Workload1 account after we create some misconfigurations. Then you’ll have the chance to change settings and see some different results, or even scan ALL your accounts (which will probably break since our instance size is too small).

This lab is just level 1- a simple cross account, non-parallelized scan. It’s something I might still do if I’m performing a hand assessment, but mostly I would use a SaaS platform our automate Prowler to run at larger scale with parallel operations.

Today’s lesson key points are:

• Cloud Security Posture Management is an essential security tool to find and fix security and compliance misconfigurations.

• Cloud Native Application Protection Platforms are the “big brother/sister” of CSPM and add in other capabilities, like vulnerability scanning the operating systems and applications in instances.

The Lab

This is an easy one- we’ll deploy a CloudFormation template in a target account, start up our Prowler instance, log in, make a quick config change, run a scan, and then review the results.

One important point: when I set up this lab I used an instance size for the free tier. This is really underpowered, and in my testing the instance would hang on a full Prowler scan. We’ll use a command line to narrow the scope of the scan which speeds things up and works every time. If you want to run a bigger scan, you can always pull the AMI for the instance, launch a new one that’s sized larger, and then run the scan.

Video Walkthrough

Step-by-Step

Start in your Sign-in portal > TestAccount1 > AdministratorAccess > CloudFormation > Create Stack (with new resources). You’ll use these settings:

• Template URL: https://cloudslaw.s3-us-west-2.amazonaws.com/lab66.template

• Name: misconfigurations

The rest is just the defaults, including clicking the checkbox in the blue box to enable creation of IAM resources.

Wait until it’s complete in case there are any errors.

Okay, now close that tab > sign in portal > SecurityAudit > AdministratorAccess > us-west-2 (Oregon) region > EC2 > Instances. Note… if you don’t see any instances make sure you don’t have the screen filtered to “instance state = running” since we stopped the instance at the end of the lab last week.

Then:

• Click the checkbox next to the instance

• Instance state

• Start instance

• Wait about 3 minutes

We need to provide the instance enough time to start and for the SSM agent to run and connect to the Session Manager part of the service. Then Connect > Session Manager > Connect:

Once you’re connected, we will run three command lines to get things set up:

• sudo su - ec2-user (log in as the default ec2-user)

Then copy and paste this line:

sed -i '/prowler aws \\/a\  --services iam s3 ec2 \\' scan-account.sh

What’s this doing? This is our fix for that performance issue I ran into. This line gets added to the command line we use to call Prowler, and tells it to only scan 3 services: aim, s3, and ec2. The full script looks like this:

The script:

• Sets some variables, including the target account that we will send in from the command line, and the external ID which is set is our configuration file (review last week to see how we did this).

• It also sets our target S3 directory for the report.

• It runs Prowler with those settings, and limits the scan to only those 3 services.

• It outputs links to get to the reports for the scan. This just makes your life a lot easier (as you’ll see in a few minutes).

If you want to see the scripts in the directory just type ls to list the contents and cat <filename> to see the file.

All your prep is done, so hop back over to your sign in portal and copy out the account ID of TestAccount1:

Now start your scan with bash scan-account.sh <paste in the account ID>

There’s a little cloud magic going on now:

• Your instance has a role with permissions to assume the scanning role in the target account.

• We provide Prowler with the role and the external ID in our script.

• Prowler assumes the role in TestAccount1 using the external ID that was passed in originally in the user-data field (last lab).

• This setup will work to scan any account in your organization except your management account.

It will take 5 minutes or so to run, maybe less. Once it’s finished click the link (or copy/paste) to go to the directory in S3 with your results:

You can download any or all of them, but for this lab start with the HTML version. Click on it, then download, then open it up in your browser (just drag and drop the html file into your browser):

Woah, that’s a LOT of results! And even if you filter out to only FAIL you still… have a LOT of failed checks. This is the fundamental problem of CSPM! Every single tool on the market is VERY noisy. It’s up to you to understand and prioritize the results. This is why I really worry when I advise an organization and they are completely tool driven and the security team doesn’t really understand the fundamentals of cloud. That’s one of the main reasons I waited a year for a lab on a tool I normally use day 1; I needed to make sure you had solid fundamentals so you could interpret the results.

AND WE ONLY SCANNED 3 SERVICES!!!

For example, look at the Network ACL results. There are a lot of failed findings there for things like leaving default NACLs. Guess what? I always leave default NACLs! This isn’t Prowler’s fault, since some compliance standards say you should lock down your NACLs all the time. This standards were probably written by someone who hasn’t ever seen a cloud in the sky, never mind AWS/Azure/GCP/TheBadPlace.

Okay, the next bit of this lab is a little choose your own adventure. I recommend you do the following:

• Filter the results and try to identify which ones you would consider important.

• See if you can identify the 3 misconfigurations (well, maybe 4) that I have in the CloudFormation template. Then go review the template to see if you found them all.

• There’s a stopped instance in TestAccount1. Start it, run another scan, and see if your results change and how.

• Scan different accounts.

• Try the scan-all-org.sh script. If you do this you MUST increase your instance size or add the services line to the script so it doesn’t max out your instance. (use the same sed line but change the target file name).

  • This scripts calls the AWS Organizations API, lists all your accounts, and then runs the scan on each account serially.

• Download the CSV file and play around with sorting and other spreadsheet stuff I can’t do because I hate spreadsheets.

There’s a LOT of information in this deceptively simple lab. Take your time, play with Prowler, and get a sense of things. As a reminder this is not the best way to run Prowler!!!! I have it running in a way that works very well for labs, but in a real situation I would use the web interface instead of saving files to S3.

Phew. Cya in the next lab where we’ll learn about yet another way to use CSPMs!

-Rich