Skip to main content

Responses are generated using AI and may contain mistakes.

Context ManagementContext Management Administration Guide

Anomali Context Tables

icon-anomali.png

The Anomali option is designed to streamline the process of creating a new context table to onboard threat intelligence data from an Anomali source, including data such as threat detections and indicators of compromise. When an Anomali context table is onboarded, it processes either IP or domain attributes that a corresponding cloud collector has ingested from an Anomali threat intelligence source that supports the STIX/TAXII standard framework.

When the context table is onboarded, it normalizes Anomali context information so that it can be mapped to Exabeam target attributes. This data is used to enrich security content that can be leveraged by downstream services such as Search, Correlation Rules, and Dashboards. By default, Anomali tables map a set of specific IP or domain attributes that are compliant with the Exabeam common information model. This model defines standardized objects for security content across Exabeam products.

The Anomali option is available on the Context Library tab. However, to create an Anomali context table, you must first create an Anomali cloud collector in the Exabeam Cloud Collector service. To further streamline the process, you can opt to have the Anomali context table created automatically from the cloud collector itself. Once the Anomali context table is running in the Context Management service, it can begin processing the data sent from the cloud collector.

Note

  • Only one Anomali context table can be created for each Anomali cloud collector.

  • Data in the Anomali context table is refreshed every 24 hours so that your view of threat intelligence data remains up-to-date.

Data in STIX/TAXII-based context tables expires according to the Maximum Age in Days options configured in the corresponding cloud collector. Data expiration avoids maintaining threat indicators for too long. It prevents aging data from becoming inaccurate and resulting in false positives. The following scenarios illustrate how the aging logic operates to remove expired data in a context table:

  • Scenario 1: A new cloud collector is created with a Maximum Age in Days = 30, and a correspinding cloud collector is auto-generated

    In this scenario, the context table is created with data from the past 30 days. Each day a tracking service pulls the delta of new data into the context table and older expired data is removed.

  • Scenario 2: A new cloud collector is created with a Maximum Age in Days = 0, and a correspinding cloud collector is auto-generated

    In this scenario, the context table is created but contains no data initially. Each day a tracking service pulls data into the context table and any previous data is removed. This scenario is useful for clearing out indicators of compromise on a daily basis.

    Note

    If you update the Maximum Age in Days value for an existing cloud collector, the data contained in the corresponding context table does not change immediately. Changes take place only on the next tracking service data pull.

For more information, see the following sections: