Prerequisites

• An AWS Organization. This one works even if you don’t have our standard lab structure.

The Lesson

At the start of our series on Cloud Security Posture Management I mentioned that we would explore the three main options, each of which you will encounter at some point if your job touches cloud security:

• Open Source. We used Prowler, which also offers a commercial version.

• Cloud Service Provider (CSP) native. We used AWS Security Hub (which is in transition as I write these labs).

• Commercial. Which we will cover today, using the Cloud Defense product from FireMon.

Note that this barely scratches the surface — there are many open source and commercial tools on the market (heck, there are currently 2 Security Hubs!). But by the time we are finished you will have a very good sense of different deployment options, capabilities, and user experiences.

There are two main learning objectives for this lab:

• See how to deploy a third-party, SaaS-based security tool connected to your AWS Organization.

• Understand a real-time detection architecture. (Similar to what we deployed for our S3 lab series, but at larger scale).

• Get a big-picture understanding of CSPM capabilities.

We will follow up with one more lab which goes into more detail on using a CSPM to detect and investigate misconfiguration.

Disclaimers and Disclosures

I debated a fair bit on using commercial tools in any of these labs, or even an Open Source tool (with commercial options) like Prowler. But you’ll encounter these tools in the wild, and I can’t teach certain skills using only what AWS provides. Besides, that would also be problematically biased because, in many cases, a third-party tool will be the better choice. With that out of the way…

• Today we will use FireMon Cloud Defense, a commercial CSPM.

• I founded the startup that was acquired by FireMon and became Cloud Defense. I worked there full-time for 3 years and still have an ownership stake, so if anyone ever buys FireMon I can stop paying for beer with stock certificates (VC/tech stuff is weird).

• FireMon already had a free tier, but they stood up a special, isolated version for these labs. It’s a complex architecture but all Infrastructure as Code, so they literally just copied and pasted into a new AWS account(s).

• FireMon created a special CloudSLAW deployment process which automates nearly everything in a single CloudFormation stack run from the management account. It even auto-registers using your management account email address.

• Everything is free for 60 days, then it disables itself. You will never be billed. They wouldn’t know how to bill you even if they wanted to.

Having our own little sandbox for these labs is pretty great, and I want to thank Brandy Peterson (one of my co-founders) for making it all possible.

Why Every CSPMs Has an Inventory

Let’s think about everything we’ve learned about assessing configurations, in the context of preventing attacks.

You’ve already seen multiple ways of scanning for misconfigurations. From the timed serverless scans we built ourselves, to running code in an instance like Open Source Prowler, to manually checking things. The problems with all of them are time, scale, and the overhead of actually looking for misconfigurations. And that’s before we get into the problem of API service limits (the number of API calls you can make in a period of time).

This is why every single major CSPM platform uses its own inventory. Instead of making a lot of costly API calls to run different assessments on the same (or different) resources, the tools:

• Sweep through accounts and run the API calls to gather all the configuration information on what’s running.

• Store it in a database.

• Run assessments against that database, which is more flexible and efficient.

• Keep the database updated.

Think about the problem: if I want to run 20 different kinds of assessments on an Instance, that would be a lot of repeated API calls. And sometimes I want to know things like “is this instance in this security group?” which is also a pain to run on its own. But if I have all that data in a database, those are queries rather than API calls, and a lot more efficient. Having an inventory gives you a better picture without having to poke the cloud provider every time.

The problem is that you still need to collect that information, and keep it up to date. Different tools handle that on their own schedules — ranging from every few minutes, to every hour, to once a day. They still need to make those DESCRIBE API calls to get the updated into.

A few platforms, including Cloud Defense, update their inventory in real time. It’s kind of a cool approach (I didn’t code it, but I did work on the initial design). It is similar to what we previously did in our real-time autoremediation lab.

Here’s how it works:

• Capture all the CloudTrail calls via EventBridge.

• Filter those calls for any “change” events (create, update, delete).

• For each event, extract the resource identifier (e.g., the instance ID).

• This triggers a lambda which reads the configuration of only that resource.

• This updated configuration is stored in the database.

• That change event triggers all the assessments associated with that resource type.

This is weirdly more efficient that running timed scans, since it only requests updated information. However, since things can slip through the cracks, any platform which uses this model should still run a daily scan (and with Cloud Defense, you’ll see it also run an initial scan when it first onboards a new account).

Go reread our old labs, because we already implemented simplified versions of this. I mean, I originally came up with the idea, so I need to milk it for all it’s worth.

Automating Deployment

There’s kind of a cool thing going on with the deployment that you’ll see in a minute, and it’s worth explaining. Actually, two cool things:

• We only deploy a single CloudFormation Stack in a single account, but somehow it deploys the tool into all our accounts. What happens is the Stack creates the StackSet, which then deploys the required resources (IAM role and EventBridge stuff) into the rest of the organization. It’s more complicated to build, but done well can be easier and more reliable than messing with StackSets directly.

• The stack auto-registers with the Cloud Defense platform and creates your account there. This uses Lambda functions, and you can read all the code in the template. For our labs FireMon created a special version which pulls our management account email and auto-registers using that as your username (I requested this to save us steps).

These are some common techniques used in more-advanced infrastructure as code, and if you read through the template you might notice some of the other things we’ve learned in these labs (like unique external IDs).

The Lab

This lab is mostly setup and exploration — we will follow up with the next lab, where we’ll run through the core capabilities of CSPM.

The setup is kind of cool, especially that they been it tuned for CloudSLAW, even though it’s a commercial tool. And as a reminder this is running in a separate version of Cloud Defense that FireMon stood up just for these labs, isolated from their current production environment.

Video Walkthrough

Step-by-Step

Start in your Sign-in portal > CloudSLAW > AdministratorAccess > (double check you are in the Oregon region) > Organizations > copy out your root OU ID (r-xxxx):

CloudFormation > Create stack > With new resources:

Use the following:

• Name: CloudDefense

• S3 URL: https://cloudslaw.s3-us-west-2.amazonaws.com/lab68.template

The ONLY parameter you should change is to paste in your org root OU ID (which starts with ‘r-’, not ‘o-’):

Don’t change anything else, run through the rest of the screens, and Submit.

This is a complicated stack which:

• Creates some resources in your management account for onboarding that account with Cloud Defense. Remember, normally a StackSet won’t deploy into the management account! Using a normal stack gets us around that.

• It creates a Lambda function to collect the email of the management account, and then use that to create a new customer account with Cloud Defense. This was the magic little bit I suggested to FireMon to make the lab easier. This feature is not part of the process as a paying customer, where you might want things configured differently.

• It creates StackSets in Virginia and Oregon and pushes them into every account. Technically we could have deployed to just certain OUs (this was the parameter where we used the root OU instead).

That’s the magic bit special for this CloudSLAW lab — auto-registration. Outside this lab you need to create an account with your SaaS provider first.

I recommend taking a look at this stack, and then the StackSets it deploys. You’ll see an external ID, as we discussed in our Prowler lab, and some other more-advanced techniques like integrating Lambda registration functions (which we previously used) and nested stacks (common in larger deployments).

As this stack is running, go check your management account email! You’ll have an account registration message from FireMon (check your spamtrap if you don’t see it within 5 minutes). Click Activate My Account:

I’m planning at least one more lab on this platform, so set a password you won’t lose. As a reminder, this account will be shut down in 60 days, and I’ll show you how to remove the stack in the next lab:

IF YOU RUN INTO ANY ISSUES CONTACT ME DIRECTLY AT [email protected]. Since this is free I’ll be handling support — not FireMon.

Once you’re logged in, click the little side arrow to expand the left menu and start exploring:

Your CloudFormation stack is probably still running and provisioning all your accounts (FireMon set a limit of 10 accounts, which is plenty for us… their commercial version supports thousands). It takes time for Cloud Defense to do its first sweep of all your accounts to fill in the Inventory. But you can click it to watch it work.

Assessments are all performed instantly as each resource lands in the Inventory, so you’ll see those results filling in as well — the entire platform is serverless and event-driven:

This is a fully functional version of the platform. The only limit is the 10 accounts, and it has some internal governors running to keep costs down, so it may be a little slower if hundreds of you sign up all at once (or maybe not — nobody’s ever tested this lab version).

Feel free to poke around and explore the capabilities. In the next lab we’ll learn how to filter results and create exemptions, then investigate a misconfiguration. These are core skills you’ll need no matter which platform you end up using.

-Rich