Skip to main content

Exabeam SearchExabeam Search Guide

Search Best Practices

Depending on the size of your environment, the logs stored in your Exabeam environments may add up to petabytes of data. Searching through this much data can take a long time. However, there are several ways to speed up the search process.

Narrow Down the Time Range

This may be the most straightforward approach: the longer the time range selected in the Search Bar, the more data that will have to be searched. In most cases, the search duration will grow linearly with the number of days or months needed to be scanned.

Avoid Using Free Text Search

Free text search can be very inefficient and we recommend that you search using parsed fields instead, unless free text search is your only option.

If you must use Free Text Search and are searching for a common term, a URL, or something with special characters, we recommend enclosing the search with backticks.

Search breaks up tokens based on special characters, so if you wanted to search for the following: https://www.abc.com, Search would break this into several tokens (http, abc, www, com) and the raw log would be searched for all of these terms separately, in no particular order. Not only would you not get the results you want, but it's inefficient in terms of both performance and cost.

Use Parsed Fields and Values

Parsed fields and their values are stored in a separate data partition that is typically much smaller than the raw data it ingested. By using field names and values in the query string, you can help Search find logs more efficiently.

This query, looking for user John within the Okta logs, will run slowly because it forces Search to look for these keywords anywhere they might exist in the raw logs.

Okta john

This query leverages field names and values to point Search to a smaller partition and will complete faster than the previous one.

vendor:"Okta" AND user:"john"

Leverage Metadata Fields

When querying raw data from unparsed logs, use the metadata fields. Because the collector used to capture a log is automatically a parsed metadata field, you can include "m_collector_name" or "m_collector_type" in your search query.

SearchMetadataFields.png

Use Common Information Model Elements

The Exabeam Security Operations Platform has improved how the results of searches including special characters that are standardized delimiters.  

For example, when searching for an email address such as "fname@domain.com", you might not get the expected results because of the @ character included in the string.   This would result in you needing to use the "keyword" field in a search like "email.keyword:"fname@domain.com"".

Now with the Exabeam Security Operations Platform, you can simply use one of the many parsed email fields to get the expected results.

SearchCommonEventFields.png

Start Small

Whenever possible, start with a narrowly focused search and increase the scope as needed for your investigation.  

For example, you can create a search query that uses a Subject, Activity, and Product to find a small number of results:

subject:"file" AND activity:"read" AND product:"Microsoft 365" 

And then expand the scope to include all activity types by removing the Product field.

Use Precise Syntax

Take advantage of Searches syntax that allow you to be very precise, and helps to eliminate any ambiguity.

Exact String Match

In the following query:

url:"www.example.com/example?time_range=2-days/"

The / and ? characters are a literal part of the URL path, but since they are also Regex special characters, Search will treat this as a Regex query and interpret the ? character as a wildcard, and not as part of the URL path.

In addition to producing incorrect results, because these characters are interpreted as special characters, this search will be very slow.

If you want these characters to be treated as part of the literal URL path, use exact string match syntax:

url=="www.example.com/example?time_range=2-days/"

Regex and Wildcard Syntax

  • Use RGX (case-sensitive) and RGXi (case-insensitive) to explicitly indicate that what follows is a Regex query.

  • Use WLD (case-sensitive) and WLDi (case-insensitive) to explicitly indicate that any special characters that follow should be treated as wildcards.

    For example, in this query: WLD(“Micro*”), you are stating that the * character should be treated as a wildcard.

See Query Syntax for more information and examples.