Cribl Search is a Cribl product that allows IT Ops, Observability, and Security teams to search their data in-motion and at-rest from several third party sources and other Cribl products such as Cribl Edge and Cribl Stream. Cribl Search uses Kusto Query Language (KQL) to query this data and can be used for searching, aggregations, and/or visualizations. Cribl Search comes out-of-the-box with several Datasets such as internal Cribl audit logs and the ability to read directly from Amazon S3 buckets as well.

Cribl Search can extend to read data from other data lakes, data warehouses, direct APIs, and object stores which are detailed in the Connect to Data section of the Cribl Search documentation. For more information on the concepts see the Basic Concepts section of the Cribl Search documentation. At a high-level, there are Dataset Providers which are where the data is stored such as in Cribl Edge or direct APIs and contain parsing and connectivity data. The Dataset is akin to an “index” or “table” or “target” from the Dataset Provider to perform searches. Query integrates at the Dataset layer by directly interfacing with the Search API to submit and process queries.

When using the Query integration with Cribl Search, you can parallelize across a nearly limitless (pursuant to rate limits in your Cribl tenant) amount of Datasets and have all the data returned normalized in OCSF/QDM format regardless of the downstream data format. Each configured Connector that can fulfill the query plan from the Query Federated Search is queried in parallel and results are re-used for up to 20 minutes per search in Cribl Search. On average, results should return in 15-35 seconds depending on the size of the data and amount of normalization.

Query integrates with Cribl Search by translating searches into specific Cribl Search KQL queries, setting limits for time, data scanned, and results returned, and transforming the data into OCSF/QDM following the mappings set by customers in our Configure Schema no-code mapping utility for mapping OCSF from any Cribl Search Dataset. The Query Connector for Cribl Search handles schema introspection, query translation, query optimization, normalization and Reverse ETL for you without needing to learn KQL or even visit the Cribl Search console.

This allows your IT, Observability, Security Operations (SecOps) teams, and other security personnel to worry more about their jobs to be done and less about configuring parsers, data packs, and transformations in Cribl Edge or Cribl Stream. Likewise, if your team is not familiar or strong with KQL, they can use a similar interface for all of Query’s other Connectors.

Query is a read-only point solution that does not allow users to submit dangerous or overly broad KQL queries in your Cribl tenant. Only the data you request in your search is brought back from the Datasets that you configure within the Query federated search platform – this data is not replicated, it is simply presented back. Query utilizes the “SET” statements to prune down to specific time ranges, payload limits, record limits, cache reuse, and timeouts to avoid cost overruns and throttling.

Security teams are increasingly becoming reliant on modern data warehousing and data lakehouse technologies to increase their data visibility and retention, in part due to the cheap storage costs in these platforms. Cribl allows SecOps teams and other related functions to quickly migrate to these platforms or to increase the reach and amount of data they have access to. 

Using Query Federated Search, you can immediately unlock the benefits of data in Cribl Search Datasets for IR, Threat Hunting, Internal investigations teams, internal audit, compliance, and other security architecture and analyst teams. While Query does the heavy lifting for you, your team can continue to upskill and adapt their data architecture to meet the modern security needs of a data-heavy environment.

For more information see our documentation on the Cribl Search integration here.