Types of Anomali Search

Anomali Search offers four search types, each optimized for different use cases:

See Choosing the Right Search Method to Optimize AVC Usage to determine the search method that has the most optimal AVC usage for your application.

Type What it is When to use Key guidance & best practices

Field-based Search

Default

eventlog Search (default)

  • Searches normalized security telemetry in the eventlog dataset.

  • Supports structured and extracted fields.

  • Default if no dataset specified.

When you know the schema(for example, src_ip, user, event_name).

Indexing Latency: 10-30 seconds after ingestion.

 

Filter strategy

  • Lead with sourcetype as the primary constraint.

  • Use parsed or normalized fields.

  • Do not use message contains as a substitute for structured fields.

Prioritize parsed fields

Parsed fields are significantly more efficient than raw message searches. Use structured field searches wherever possible.

✗ High AVC: | where raw_message contains_ci ("John")

✓ Recommended: user = "John"

Avoid message field on large ranges

If you must use message, restrict the query to a 24-hour window and always pair it with a sourcetype filter.

Operator order

Place where clauses before calc, rex, and json_extract to skip unnecessary processing. Place limit last to avoid non-deterministic results.

Use definitive operators

Prefer = and != over contains or contains_ci for accurate, efficient filtering.

Use normalized fields

Check if a JSON field has a normalized column in the eventlog schema and use that directly instead of json_extract(message, ...).

Avoid wildcards on sourcetype

✗ sourcetype contains '%'

✓ sourcetype = 'defender'

Stagger scheduled tasks
Distribute alerts and reports across a time window (for example, 2–3 AM) instead of triggering them simultaneously..

OCSF Search

  • Stores event telemetry normalized to the OCSF Version 1.2 schema.

  • Uses nested object notation.

  • Requires the case-insensitive keyword prefix "ocsf"

  • When your data is normalized to the OCSF Version 1.2 schema.

  • When querying across multiple vendors or log sources using standardized OCSF field names.

  • When filtering by OCSF event category (for example, Network Activity, Discovery).

  • When you need OCSF dotted-notation fields such as src_endpoint.ip or actor.user.name.
Indexing Latency: 10-30 seconds after ingestion.

 

Filter strategy

  • Lead with category_name as the primary constraint (equivalent of sourcetype in eventlog).

  • Use OCSF dotted-notation fields. Do not use flat eventlog field names in OCSF queries.

  • Do not use message contains as a substitute for structured OCSF fields.

Prioritize nested fields

OCSF fields are pre-indexed. Querying them is as efficient as querying parsed eventlog fields.

✗ High AVC: | where message contains_ci ("10.0.0.1")

✓ Recommended: ocsf | where category_name = "Network Activity" | where src_endpoint.ip = "10.0.0.1"

Operator order

Place where clauses before calc, rex, and json_extract to skip unnecessary processing. Place limit last to avoid non-deterministic results.

Use definitive operators

Prefer = and != over contains or contains_ci for accurate, efficient filtering.

Stagger scheduled tasks

Distribute alerts and reports across a time window (for example, 2–3 AM) instead of triggering them simultaneously.

TurboSearch

Accelerated

(Field-based and keyword search on specific fields)

Optimized search, designed for high-speed lookups on specific indexed fields.

  • Searching for exact values in known indexed fields.

  • Multi-value IOC sweeps.

  • For Forensic and retrospective searches on large datasets, threat hunting.

Indexing Latency: 10 minutes after ingestion.

 

Query Type

Can specify a keyword or field-based search queries. Values are searched only in the indexed fields as described below.

Indexed fields

account_id, dest, dest_ip, dvc_name, file_hash, file_hash2, file_hash3, file_name, host, http_referrer, message_id, query, src, src_ip, url, user

Match Behavior

- Prefix* and exact match are supported.

- Wildcard, suffix, and “contains” (i.e., partial matches within a string) are not supported.

Time Range Guidance

Use for any time range

AVC Impact

Use Turbosearch as the initial operator. Combine with indexed fields and parsed field filters for low AVC.

 

Examples

|turbosearch "1.2.3.4"

|turbosearch src_ip = '1.2.3.4'

|turbosearch sender='sender_example@example.com'

|turbosearch "https://www.example-url.com/feed"

|turbosearch "tech@acmecorp.com", "examplefilehash" | aggr count (sourcetype) as srctype_count

Full-Text Search

Keyword

Keyword search on raw log messages using full-text indexing.

 

Faster and lower AVC cost than searching the raw message (using message contains)

  • You do NOT know field names

  • Searching for exact keywords (emails, strings, IDs).

  • Only applicable to eventlog.

Indexing Latency: 10 minutes after ingestion.

 

Syntax requirements

Keyword must be at the start of the query, wrapped in double quotes. Search is case-insensitive.

✓"john.smith@company.com”

✓ "john.doe@company.com" | where sourcetype="email_logs"

Tokenization

  • Valid tokenization characters: letters, digits, dot (.), dashes (-), underscore (_).

  • Delimiters: spaces, punctuation, and special characters.

Match Behavior

  • Exact matches only.

  • Does not support wildcards, partial matches, or substrings, including for sourcetype.

 

Boolean Support

AND and OR supported but not NOT

 

Case Handling

Search is case-insensitive. For example, "Error" and "error" are treated the same.

 

Time Range Guidance

Use for any time range

 

Turbosearch vs Full-text

More granular than Turbosearch keyword search as Turbosearch matches full values while full-text matches tokens.

Example: For user = john.doe@company.com

Turbosearch:

user = "john.doe@company.com" will match

user = "john" will not match

Full-text:

"john" will match

"doe" will match

"company.com" will match due to tokenization rules

Table / Lookup Search

Enriched

Search against pre-enriched or correlated datasets: iocmatch, threat_models, audit, and so on. Reduces scanned dataset versus default eventlog.

See Using Lookup Tables for more information.

  • When working with pre-enriched data or correlated threat intelligence.

  • When you want to narrow the dataset away from the full eventlog.
Indexing Latency: 15 minutes after ingestion
System tables are updated every 10 minutes
 
Specify the table explicitly

Name the target table at the start of the query to avoid a full eventlog scan.

✓ iocmatch | where action in ('allow', 'accept')

✗(higher AVC) eventlog | where action in ('allow', 'accept') | where src_ip = "1.2.3.4

array_agg limits

The array_agg operator is capped at 50 distinct values. Use low-cardinality fields, filter data before aggregating, or use group by for high-cardinality fields.

dedup guidance

Use dedup on small, pre-filtered datasets only. Never apply it to the message field — each raw event is held in memory, hurting performance.
Forensic / Retrospective Search By default, Anomali Search retains event data in hot buckets for 90 days, after which it moves to archive buckets based on license retention terms. Searches run only on hot data by default to control AVC usage. Access to archived data requires approval via a support ticket, after which your account can be enabled for extended searches. Once enabled, use eventlog, Turbosearch, or full-text search to search.