Enrichment Lists

Running searches is often a very static experience. Users search for key words or phrases that they know in order to return specific results. An enrichment list is used to map a lookup key to an enriched value.

If the data you want to search is more dynamic and changes often, it might be difficult to create a query that would collect the right information. In such cases, you can use an enrichment list and reference the list in any query or in Predefined EQL Functions to achieve accurate results. From the Advanced Search tab, you can use an enrichment list in your search query. LogLogic LMI provides some built-in enrichment lists, for example, mapRuleAction. You can refer to the built-in lists as a guideline to create your own.

Use the following syntax to run a search query with an enrichment list:

 use 
		  <nameOfDataModel> | $<NameofEnrichmentList>(<lookup_key> [,<default_value>])='<comparison_value>'

where:

<nameOfDataModel> is the name of the data model to be queried
<NameofEnrichmentList> is the name of the enrichment list
<lookup_key> is the key to be looked up. If it is a column name, the value of the column for each row returned is used to look up the enriched value. It can also be a constant, in which case it always returns the same result. If there is no mapping for the lookup key, the enriched value is NULL.
default_value is an optional parameter which, when provided, is the default return value when there is no mapping for the lookup key.
<comparison_value> is the value that you want compared with the enriched value produced by the enrichment list.

For example, consider the search query:

use LogLogic_Appliance |$ipBlackList(sys_collectIP)='blacklisted'

The Enrichment List ipBlackList contains some value mapped to the key name blacklisted. This value is searched in the column sys_collectIP of the data model LogLogic_Appliance. We want the search result to display all log events that match the comparison value blacklisted.

Note: The behavior of the operators = and != is similar to that in regular SQL. If one side of the comparison has the value NULL, regardless of which operator is used, the result of the comparison is NULL, which is evaluated as FALSE in a WHERE clause. This results in both = and != returning FALSE if there is no mapping for <lookup_key>, which might not be what you expect, especially for !=. A better solution is to use the !== operator instead of !=. This returns TRUE if one side of the comparison is NULL, which is a more expected result. For more information about the operators == and !==, see FILTER Statement.