When we decided to launch a free version of FireMon Cloud Defense we knew we would have to balance two key challenges:  

• We already knew our platform could scale, but could we adapt it to economically scale to support large enterprises for the long term? Needless to say we couldn’t simply release it and hope our AWS bills didn’t force us into receivership. 
• With the economic limitations, could we provide a feature set that delivered real value to users? What would that value be? What problems would it solve?

The reality is “free” (as in beer) is never totally free since using anything takes time and effort. We don’t look at the Cloud Defense free tier as crumbs we dribble over the edge of the table, we know that if we are asking users to sign up, deploy, and engage with the platform they will only do that if we help them get their jobs done.  

(What do we get out of it? Well, we know some percentage will move up to our paid plans, but the free platform will help us get incredibly valuable feedback on what people want from their CSPM and how they use it and let us test out new ideas).    

In future posts we’ll talk about the technology in more depth, but today we want to walk through our process for how we decided which features to package into the free tier. Since we view this version of the platform as its own product, we decided to use the same methodological approach that guides much of our strategy.  

Defining Desired Outcomes 

Here at FireMon we are big fans of the Jobs to be Done framework for product strategy. The name is a bit of a giveaway, but the framework guides product decisions by focusing on what job the customer is trying to do, and what specific outcomes they expect. This is a gross simplification of the JTBD framework, but you get the idea. Rather than focusing on features you focus on a potential customer’s desired outcomes when using a product and then use this to design features. 

After going through an in-depth process that included research, experience, and interviews, we honed in on a draft set of possible desired outcomes for cloud security professionals: 

• Improve my knowledge and understanding of our cloud posture across our entire cloud footprint. (visibility) 
• Minimize the likelihood of a cloud misconfiguration being configured across our cloud footprint. (prevention) 
• Reduce our cloud security and compliance exposures (volume and time) across our cloud footprint in a decentralized environment. (remediation) 
• Improve our ability to communicate cloud security issues to management and regulators. 
• Reduce the potential for loss and abuse of IAM access to our cloud deployments.   
• Improve our ability to prevent, detect, and respond to cloud attacks 
• Keep our security up to date with changes to cloud services and platforms across multiple providers. 
• Reduce security friction and overhead on development and cloud teams without increasing our security risks. 
• Reduce the risk of a security breach when we deploy using containers. 
• Reduce the time I spend integrating cloud security with my program with standard APIs and data structures. 

Clearly there are a lot of ways to address each of these problems, so the question to us was, which could we provide with the economic constraints of running a free, hosted platform? It’s very different than providing Open Source Software someone needs to deploy and run on their own. We wanted to build something that was as fast and easy to use as a commercial product (okay, hopefully faster and easier than a lot of the products you’ve used in the past). 

Translating Outcomes to Features 

With that list it was time to see what we could adapt or build:  

• Improve my knowledge and understanding of our cloud posture across our entire cloud footprint. (visibility) 

Posture isn’t necessarily just about security; posture is how things are configured. Since merely providing a list of misconfigurations wouldn’t communicate posture we knew we would need to build a cloud inventory, at enterprise scale, within our cost constraints. Our platform already supported a real-time inventory but it wasn’t cost-effective to scale that to the free tier.  

We decided we could balance costs and still provide value with once-a-day scans and a 30 day inventory history with change tracking. You’ll notice we aren’t talking about security misconfigurations yet, but we’ll get there. After running some cost modeling we realized we could run this at enterprise scale (thousands of monitored accounts) within our budget, so this checked both boxes of providing value while managing costs.   

This actually took quite a bit of engineering effort since the commercial product primarily supported real-time inventory updates instead of periodic scans. However, we packaged those updates with some other changes we wanted to make that improved overall efficiency so they aligned well, making it an easy decision.  

• Minimize the likelihood of a cloud misconfiguration being configured across our cloud footprint. (prevention) 

Preventing cloud misconfigurations is a much harder problem than detection. Do you block it in the CI/CD pipeline if they are using Infrastructure as Code? What about manual changes? How do you handle the workflows without adding too much friction or breaking things?   

We knew we couldn’t implement full prevention within a free product at this time. Our current platform handles this via automation, which would be too costly to run at scale for free. However, we have some ideas that might work and are now in our development backlog. 

• Reduce our cloud security and compliance exposures (volume and time) across our cloud footprint in a decentralized environment. (remediation) 

This has been the bread and butter of Cloud Defense since the first versions of the product. While automated remediation wouldn’t work for our free tier (again, balancing cost and complexity) there was no reason not to run our full suite of security checks.  

But getting a long list of potential security issues doesn’t necessarily help you remediate. One of the other core capabilities of our product is deep ChatOps integration. Out of the box we supported Slack and Teams, but Teams would require more support due to… well… it’s Teams. So we made the decision to fully enable our granular (per-account or project) Slack notifications since there was no material cost to us, and a lot of value to users.  

• Improve our ability to communicate cloud security issues to management and regulators. 

Our internal costs to run a compliance report are negligible, even for large environments. For compliance, once a day assessments tend to more than meet this desired outcome. We did have to put in some new development effort to support better PDF reports for larger deployments (e.g. hundreds of accounts), but we needed that for our commercial customers anyway. 

• Keep our security up to date with changes to cloud services and platforms across multiple providers.

Since our free and commercial products use the same library of checks that we are constantly updating, this was enabled out of the box. Our initial engineering effort focused on cost-optimizations for AWS so we decided to launch without Azure or GCP support at the start. Azure is just about ready so users will eventually get full multi-cloud support for free. 

• Reduce the potential for loss and abuse of IAM access to our cloud deployments.

We have a pretty awesome feature called Authorization Control that materially improves IAM security, but the economics just didn’t work to put it in the free product.  

• Improve our ability to prevent, detect, and respond to cloud attacks

Our commercial product supports real-time threat detection, but this was another feature where the economics just didn’t line up to support for a free platform due to the high volume of activity we have to monitor in a real-time basis.   

• Reduce security friction and overhead on development and cloud teams without increasing our security risks. 
• Reduce the risk of a security breach when we deploy using containers. 
• Reduce the time I spend integrating cloud security with my program with standard APIs and data structures.

These outcomes all added costs and/or complexity that we didn’t feel we could adequately address in the free product due to either infrastructure, support, or development costs.  

Packaging the Feature Set 

The desired outcomes, combined with our cost analysis, helped us decide which features to package: 

• Once a day scans 
• Resource inventory with a 30 day history 
• The full suite of security checks 
• Foundational compliance reports 
• Slack integration 
• AWS for now, Azure and GCP as we update the platform 

These weren’t always easy decisions. For example, even a 30 day inventory comes with costs, but we didn’t feel just shipping misconfiguration reports would adequately address a user’s visibility needs. We also decided that limiting our security checks or requiring someone to move to the commercial product for compliance reports would also result in a product that didn’t really provide a sufficient outcome.  

This collection addresses the core security visibility desired outcomes, and the communications outcomes to improve both reporting and reduce remediation timelines. And we know there’s value here since these are the desired outcomes people first built cloud security OSS tools to address, and were the origins of the entire Cloud Security Posture Management market. 

The JTBD framework really helped us keep our focus on improving customer outcomes, rather than just peeling off some features that, together, don’t really help anyone. We think the end result is a free platform that delivers real value while being so cost-efficient we can support it for the long haul. 

Check it out, and tell us what you think. FireMon Cloud Defense is a work in progress and a great way for us to improve our ability to help cloud security professions get their jobs done.