Today RunReveal is announcing RunReveal Destinations. Since starting RunReveal we've met dozens of security teams and many of them are writing and maintaining integrations with "point-solutions" just to collect their logs and store them somewhere for a rainy day.

RunReveal wants to help security teams make the process of collecting their security data in one place much easier. We're planning to release this feature in Q2 of 2024.

Want to become a design partner? Sign up below.

Last year we launched Bring Your Own Database specifically geared around Clickhouse. RunReveal Destinations is an extension of BYODB which is already in use today.

Why stream logs somewhere else?

There's an obvious trend in security engineering where engineers are collecting logs, streaming them to a bucket, and then using some tool of their choice to load and query those logs.

This strategy has some obvious advantages. First, a lot of security teams want to delay the decision about any heavyweight tool that they store logs in. Collecting the logs in something like a storage bucket gives them time before they need to make the decision about what database or interface they'll use to query their logs. Second, this is very inexpensive to maintain at first since raw unindexed logs don't require much compute to collect and store. Last, it provides the insurance they need if they need to deal with an incident that those logs could be searched even if it's very costly at scale.

Having full control and low up front costs, it makes sense why so many security teams have adopted this strategy. However, there still are not many open-source or commercially available products in this space. RunReveal wants to help by:

1. Helping our customers who are leveraging our full SIEM offering collect and back up logs to low-cost object storage for raw access.
2. Help customers collect their logs from third party services to make later adoption of a full SIEM solution easier.

We see this trend as something that isn't going away, but there are a few challenges with this strategy. A security engineer's time is limited and figuring out the nuances of each type of log they want to collect, and operating those automations can take a lot of effort and cycles when they break. We want to help security engineers by saving them time and helping them get their logs wherever they are needed.

How does destinations work?

You'll create a destination by providing us with the access we need to write the data to the destination of your choosing. Next, you'll need to configure the details of how you wanted your logs streamed. For example:

• The pathing / directory structure / file name and format
• The log format – raw, normalized, something custom, or all of the above.
• Which sources should be sent to the destination.

In our software architecture, we already process all logs with an abstraction that allows us to control where logs are sent. We wrote about this last year, and by default each of our stream processing features are implemented as a plug-and-play eventRouter.

[ Sources Go Routines ] --> [     Stream      ] --> [    Destinations    ]
 - CloudTrail                - Geo Enrichment        - RunReveal Backend
 - Okta                      - Transformation /      - On-prem Clickhouse
 - Cloudflare                   normalization /      - Custom Destinations
 - Azure Entra                    custom fmts
 - Google Cloud              - Error handlers       
 - Google Workspace
 - Etc  

Since Destinations were always a part of our log processing abstraction, it only makes sense that we make it customizable to allow for data to get wherever it's needed. We expect to be able to build many many destinations, and be able to churn them out at the same pace that we can add a source, but in the near term we plan to support Azure Blob Storage, Google Cloud Storage, S3, and Cloudflare's R2.

Stop maintaining integrations to point-solutions

Our goal with Destinations is to help save our customers time so they can focus on doing real security work, not the grunt work of reading API docs or details about OAuth handshakes. We recognize that a great starting point is centralized log collection in ultra-low-cost backup storage.

To use RunReveal destinations, you don't need to be using RunReveal to detect compromises. For customers who would like to be a design partner of this, we are fine taking on workloads even at multiple terabytes per day so feel free to get in contact with us.

Our goal with Destinations is to help save our customers time so they can focus on doing real security work, not the grunt work of reading API docs or managing log pipelines.

Get in touch with team RunReveal. Have lots of logs? Have lots of point-solutions? RunReveal is built for massive scale and can help you make sense of your security logs.