Security workflows, and what we’re building next

I’ve been spending a lot of time on calls with Fix users this past month, looking to understand what type of cloud security problems they’re facing and how Fix can help solve them.

As always, when you talk to enough people, common themes emerge. I keep hearing how your cloud infrastructure keeps both expanding and changing, and that security responsibilities are getting pushed down to developers since the central security team is tapped out.

So, what does that mean for Fix? As security gets pushed down to developers, we’ve heard that you want to write custom checks and queries, integrate the results directly into your workflows and build more automations. You also want more platform support beyond just AWS.

In this post, I’ll describe what we’re building to address your asks. Let’s dive in!

Custom policies and queries ​

To write queries and searches for your cloud inventory, we developed a domain-specific language (DSL) for Fix. (For background on DSLs, I recommend reading Martin Fowler’s Domain-Specific Languages Guide.)

It’s fairly easy to get started with the Fix search syntax. But to use it to its full extent, there is a steep learning curve since it uses components of a graph query language.

Fix’s asset inventory is graph-based—it uses ArangoDB under the hood. We chose a graph rather than a row-based store to reflect the interconnections across today’s cloud-native environments, which are illustrated in Fix’s neighborhood view:

Graph traversal is the magic wand that provides actionable context and helps answer questions like, “What resources sit behind this public IP address?” Defenders think in lists. Attackers think in graphs. As long as this is true, attackers win.

We of course know the complexity of graph search, so we built two things to lower the bar to adoption. Drop-down filters allow you to slice and dice your data, and example searches provide pre-configured searches that are harder to build with the drop-down menus.

Improved filtering and search ​

We’re iterating on the drop-down filters to make it more intuitive to build complex searches, so you can use graph traversal without in-depth knowledge.

Many of you have also been surprised to learn about Fix’s full-text search functionality (“I can do that?”). Fix uses a statically typed data model, and we index the data after each collect run. This allows for fast search and retrieval of any attribute. We’ve heard that this capability is not super obvious, so we’re going to change that.

More example queries ​

You’ve told us that our example queries are really useful. So, we’re going to add more!

One trend we’ve observed is the convergence of FinOps and Security, where again the responsibilities for cost and security shift to developers. We’re going to build more example queries not just for security, but also cloud cost, utilization, and reliability.

For example, Fix data already allows you to identify unused resources, like orphaned volumes or snapshots. These are usually long-tail resources where the individual cost of the resource doesn’t justify the developer’s attention. But by writing a policy and surfacing them automatically, it becomes a much easier and quicker task to delete them, which means less cloud spend and less resources to worry about.

Fix search syntax tutorial ​

Power users who want to dive deeper and write custom searches, keep an eye out for a new tutorial that goes beyond our existing documentation.

We are creating a tutorial that explains core concepts of the Fix search syntax while guiding you in building on simple searches to create complex filters tailored to your needs.

Resource model documentation ​

For users to really understand the Fix search syntax, we need to do a better job at explaining Fix’s unified data model.

Fix is built on top of our open-source project Fix Inventory, which already supports multi-cloud with AWS, Azure, Google Cloud, and DigitalOcean. I’ll cover multi-cloud support more below, but our plan is to roll these platforms as well into Fix.

Resource data models obviously differ across cloud providers, but even within a single provider they can diverge. For example, AWS uses different timestamp formats across their product portfolio.

Fix achieves consistency across both cloud providers and their resources with its resource base kind.

Every resource in Fix has the resource base kind as its root and inherits its properties, allowing for data retrieval across clouds. In short, even though Fix currently only supports AWS, we’ve built Fix with multi-cloud support in mind.

Compliance checks ​

Compliance checks and security benchmarks are written in the Fix search syntax. However, the underlying query is not immediately obvious, and that creates trust issues in the data.

You can view queries by clicking on failed checks, but the formatting is not intuitive and there’s no single place in our dashboard to find the rules used in the benchmark checks. That has made it difficult for you to troubleshoot false positives.

We currently maintain all checks on GitHub, and we’re planning to incorporate them into the Fix dashboard.

Custom policies and rules ​

This has been requested by pretty much everyone I’ve talked to. You want to create rules that are custom to your business.

We are still in the planning stages for this, but I’m imagining something like a policy editor for the Fix search syntax with editing and formatting capabilities, like in this screenshot of an S3 bucket policy:

(Programmatic) access to data ​

One of our core beliefs is that it should be really easy to get data out of Fix. Traditional enterprise security tools can make that really hard. Digital transformation and unifying data from disparate tools is something we witnessed in analytics with the modern data stack. But it hasn’t really happened in cybersecurity. Every enterprise has different security tools, and there’s a need to unify data from these tools into a single place.

API access ​

Many of you want an API to consume the data that Fix collects. Use cases include integration of inventory data into SOAR tools and CI/CD pipelines.

We already have the API under the hood, but we haven’t made it part of our product experience. This will change.

Command-line interface ​

It’s already possible to embed Fix data into your pipelines by using fixctl, Fix’s command-line interface (CLI). fixctl is still pretty bare bones, but does the job. We plan to upgrade the experience so that it’s on par with the Fix Inventory shell.

Below is a preview of what that experience will look like, with tab completion and formatted outputs:

Sync to storage buckets ​

Another request was syncing data to S3 / storage buckets, to enable further analysis and ingestion into data warehouses / analytical data stores like Snowflake, ClickHouse, and DuckDB.

Fix Inventory already has data sync capabilities, and we’re planning to include add them to Fix.

Broader platform coverage ​

As mentioned above, Fix Inventory already supports multi-cloud, with data models for AWS, Azure, Google Cloud, DigitalOcean, and Kubernetes.

Part of our “secret sauce” in Fix Inventory is that we can connect resources found in Kubernetes to resources found in the underlying cloud provider. If you have a Kubernetes cluster running, Fix Inventory will show the underlying persistent resource provided by the related cloud provider. This shows which compute instance a pod runs on or which underlying volume is provided.

In a SaaS model as with Fix, we have to install some sort of operator in your infrastructure to collect Kubernetes data. We’re considering and investigating various approaches.

What’s next ​

Fix’s role in this journey is to be the source of truth for your security data. To help you get relevant and reliable security metadata. As we’re broadening our platform support, we’ll make it easier for you to tailor the data Fix collects to your needs, and develop more and more security workflows and automations.

Stay tuned for more updates as we launch these new capabilities!