Adjust Query Syntax
Use the reference tables below to adjust different types of Data Lake query syntax for use in Exabeam Security Operations Platform applications. For additional information, see Advanced Search in the Exabeam Search Guide
Free Text Search
Syntax Type | Description | Data Lake | Exabeam Security Operations Platform |
|---|---|---|---|
Single Term | Search for a single word | enclose in " " Ex. | enclose in " " Ex. |
Phrase | Search for multiple words | enclose in " " Ex. | enclose in " " Ex. |
Boolean Operators | Use to combine or contrast | AND, OR, NOT, +, - | AND, AND NOT, NOT, OR |
Field Search
Syntax Type | Description | Data Lake | Exabeam Security Operations Platform |
|---|---|---|---|
Value in a Field | Search for a value in a field - not case-sensitive | field:value Ex. | field:"value" OR field="value" String Ex. Integer Ex. NoteFields: Names are always lower case. Values: String values are always enclosed in " " but integer values are not. However, some numbers are treated as strings and require " ". For example: |
Case-sensitive Value in a Field | Search for a case-sensitive value in a field | field:value Ex. | field:"'value'" OR field="'value'" NoteCase-sensitive Values: To find a case-sensitive, string value, enclose the value in back ticks inside the quotation marks. For example: |
Exact Match Value in a Field | Search for an exact value in a field | field:value Ex. | field=="value" NoteExact Match Values: Finds matches only when the entire value is a match. For example: |
List of Values | Search for multiple values in a field | field:(value OR value) Ex. | field:("value","value") OR field=("value","value") Ex. NoteOnly use ( ) for multiple values or groups. A single value enclosed in ( ) will result in an error. For example:
|
Range of Values | Search for a range of values in a field Range operators include: TO, >, <, >=, <= | inclusive: field:[1 TO 10] exclusive: field:{1 TO 10} Ex. | inclusive: field:[1 TO 10] exclusive: field:{1 TO 10} Ex. |
IP CIDR Notation | Query a rang of IP addresses using CIDR | Ex. | Ex. |
Field Existence | Determine if a field is present or Determine if a field is not present | _exists_:field !_exists_:field Ex. | NOT field:null field:null Ex. |
Keyword Fields | Search for exact matches using the .keyword that corresponds to a field | Ex. | Not applicable because fields are stored natively by their data type. |
Tokenized Fields | Search for fields used in the UI as substitutes for sensitive data | Ex. | Not required in Search. |
Metadata Fields | Search for fields added to an event that are not part of the raw data | prefixed with exa_ Ex. | prefixed with m_ Ex. |
Custom Fields | Search for fields created by the user | no specific marking for custom fields | prefixed with c_ Ex. |
Logical Statement Search
Syntax Type | Description | Data Lake | Exabeam Security Operations Platform |
|---|---|---|---|
Conditions | Group conditions in ( ) and join by AND/OR operators | user:(joe OR jane) | subject:("user,"app") AND product:"Windows" |
Logic Operators | Operators than can be used in logic statements | AND, OR, NOT, !, - | AND, OR, AND NOT, NOT, or leave blank for an empty string |
Wildcards | Symbols that represent one or more characters | * represents any number of characters ? represents a single character | * represents any number of characters ? represents a single character Wildcards cannot be used in stand alone expressions. |
Special Characters | Characters that have a specific use in search syntax but need to be included in a search, including: + - & || ! ( ) { } [ ] ^ " ~ * ? : _ | escape these characters by prefixing with \ Ex. string: Query: | escape these characters by prefixing with \ Ex string: Query: |
Regular Expressions | REGEX patterns can be included in search queries. For detailed REGEX search information, see Query Using Regex. | enclose in / / Ex: | enclose in / / inside of " " Ex: |
Parser Search
With the introduction of the common information model, the conventions for constructing parser names have been standardized. For information about new parser names and a link to a resource that maps old to new parser names, see New Parser Names.
Type of Parser Information | Data Lake | Exabeam Security Operations Platform |
|---|---|---|
A specific parser by name |
|
|
All parsed logs |
|
|
Any unparsed logs |
|
|
Time Parameter Search
Intro text
Data Lake | Exabeam Security Operations Platform | Description |
|---|---|---|
@timestamp | approxLogTime | Default time the raw log was parsed. |
indexTime | ingest_time | Time the parser or enricher processed the log message for indexing. |
exa_adjustedEventTime | time | Time derived from the event itself with adjustments, such as time zone, if this information is present in the log and has been parsed. |
exa_rawEventTime | raw_log_time | Non-adjusted time derived from the log message itself. If not present in the log, defaults to the time the log message was processed for indexing. (indexTime or ingest_time) |
Context Table Search
Data in context table can be accessed for search queries in both Data Lake and Exabeam Security Operations Platform. However, context table data is accessed using different methods:
Data Lake – A context table can be added as a filter to query results that have already been generated for searches, correlation rules, or dashboards and visualizations. Only the keyword fields can be searched when a context table is selected.
Exabeam Security Operations Platform – Context data is stored in multi-column tables in the New-Scale Context Management service. One custom context table can be added to a search query. It must be added at the end of the query and be joined by an AND or AND NOT operator. Only the data in the key attribute column of the context table can be searched when a context table is part of the query. For detailed information, see Using Context Tables in Search in the Exabeam Search Guide.
Common Information Model Entity Search
In the Data Lake categorization structure, data is classified either by exa_category or on the basis of the following three components: exa_activity_type, exa_device_type, exa_outcome. You can search for data based on these categories and components. By contrast, in the Exabeam Security Operations Platform, data is categorized according to the elements of the common information model, including subject, activity type, outcome, vendor, product, product category, platform, and landscape. You can search for data according to these entity types. For more information about the new hierarchical information model and its entities, see New Data Categorization.