Skip to main content

Responses are generated using AI and may contain mistakes.

Context ManagementContext Management Administration Guide

STIX/TAXII Context Tables

icon-pre-built.png

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

When the context table is onboarded, it normalizes STIX/TAXII 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, STIX/TAXII 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 STIX/TAXII option is available on the Context Library tab. However, to create a STIX/TAXII context table, you must first create a STIX/TAXII cloud collector in the Exabeam Cloud Collector service. To further streamline the process, you can opt to have the STIX/TAXII context table created automatically from the cloud collector itself. Once the STIX/TAXII context table is running in the Context Management service, it can begin processing the data sent from the cloud collector.

Note

  • Only one STIX/TAXII context table can be created for each STIX/TAXII cloud collector.

  • Data in the STIX/TAXII 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: