Announcing OpenCSPM - An Open-Source Cloud Security Posture Management and Workflow Platform

12 November 2020

OpenCSPM is an open-source platform developed by Darkbit that aims to make continuous cloud security posture assessments of cloud environments a practical reality for security and compliance teams alike. It offers a unique approach to manage the firehose of security and compliance check results that can even modest AWS and GCP environments can surface, and its control definitions allow for simple yet powerful levels of introspection of its graph data model.

Why Did We Build OpenCSPM?

Performing cloud-native and Kubernetes security posture assessments is our laser-focus at Darkbit, and helping our customers at every stage of their journey manage appropriate levels of risk in their environments is what drives us. With every engagement, we learn more and more about what drives our customers and the contributing factors to their cloud security challenges. Overwhelmingly, the challenge is getting control of and keeping control of security risks in ever-growing and changing cloud environments. It’s just too much data, too often, and the surface area keeps expanding.

OpenCSPM Demo Search

There are several SaaS offerings and open-source tools that focus in this space, but our perspective as a two-person consulting company made us see and feel a lot of our customers’ pain. It highlighted multiple areas that we wanted to address differently, and we felt the community could benefit from our lessons learned.

What Have We Seen?

You can’t manage what you can’t see. Without a complete inventory, you’re flying blind when it comes to cloud security posture management.

Design Goals

Make answering the simple questions simple and answering even the most complex questions possible.

  1. Support for cloud providers, Kubernetes resources, and other related types of data types using a standardized approach - OpenCSPM is targeting AWS, GCP, and soon, Kubernetes resources, but adding other types of data like Identity mapping, container image vulnerability metadata, and more are on the roadmap. Resources are to be collected in a standardized JSON format using dedicated collection mechanisms and delivered to cloud storage buckets like GCS and/or S3.
  2. Separation of Collection from Analysis - Scanning/collecting and then analyzing the data from a single tool is convenient, but when deployed into a cloud account, it becomes quite the target for an attacker. Having processes with just enough permissions to collect the data and write to a bucket separate from the system that ingests/analyzes that data helps minimize that risk, but it also enables more flexible deployment scenarios for larger organizations with multiple teams, each with their own levels of access to the data.
  3. Advanced Data Model - Answering lots of complex questions of this inventory and configuration data requires parsing and storing the data with relationships intact. A graph database is best suited for this task, and it provides a window to this data that makes answering the simple questions simple and answering even the most complex questions possible.
  4. Campaigns as Workflows - When making the cost of checking thousands of settings across multiple accounts extremely cheap and quick, even small organizations will generate an overwhelming amount of results they have to manage. The most important results can be triaged and tracked in one or more “campaigns”, and this is the touchpoint where activities such as filtering and notifications can be handled. You should be in full control over what to care about and be notified on, not the system.
  5. Full control - A platform with this much potential capability and power should be in the hands of the teams that need to get work done. That means full control over where that system is deployed, its access model, and fine-grained control over what it checks and how it represents that data. The system should be open and transparent about what it’s doing. More importantly, you should be able to know what it’s not doing.
  6. Compliance Objectives and Tagging - It should be possible to associate controls with one or more compliance requirements with relative ease, and the user interface, filtering, and workflows should be driven from those tags. For example, filtering controls by “PCI”, “NIST 800-53”, or “CIS” should narrow down the list to the controls that align with those frameworks with an identical mechanism that can also be used to filter controls for “lateral movement” or “privilege escalation”.

Who Is OpenCSPM For?

Organizations looking for an open-source solution to help them gain more complete control over how cloud security posture data is collected, analyzed, measured, and handled on a continuous basis. For example:

We Want Your Feedback

We’d love to hear your thoughts and get your feedback! We want to build this project to fit the needs of its users, and we want you to help us make it better for everyone.