Skip to main content

Security ContentExabeam Security Content in the Common Information Model

Common Information Model Impact on Downstream Processes

In the Exabeam common information model, context elements serve as the foundation for the hierarchical framework. They influence how logs are ingested and how all of the subsequent logic operates. Before considering how the common information model impacts these downstream processes, it's a good idea to understand the integral nature of context elements to the information model structure. For more information, see Common Information Model Context Elements.

Context Elements as a Categorization Method

Context elements provide a way to categorize events consistently both within, and across, Exabeam products. Note that a single event can be categorized in multiple ways, depending on the needs for which it is used. Context elements are the key here. Any context element that is part of an event can function as its own pseudo-category. The categorization process is not restricted to an arbitrary event name. Categorizing based on context elements allows a file creation event to be identified as such regardless of where it was created, locally or in the cloud.

Consider the following categorization examples:

  • A file subject can serve as a category for any file-related events.

  • A network landscape can serve as a category for any network-related activities.

  • A login activity can serve as a category for any type of login.

Context Element as Event Properties

Context elements are a part of every ingested log. When ingested, these elements and their specific field values become a part of the Exabeam ecosystem. Like all other fields, they can be accessed by any downstream system process.

Beyond the role of populating field values, context elements provide the driving force behind Security Analysis and activities like Search, Reporting, and Dashboards.

Security Analysis

In security analysis, context is essential for evaluating the potential risk an action poses. The degree of risk for a given action can vary depending on multiple attributes associated with a specific instance of the action. Context elements provide a way to accurately leverage these subtleties so that security features can be conditioned, scoped, and detected with great reliability.

Consider the following security analysis examples:

  • Suppose that a new privilege escalation vulnerability has been released for a specific application. Using the platform context element, we can accurately detect privilege escalations for that application. The results will not be diluted with data from other platforms or event types and the risk of triggering false positives will be reduced. Anomalies can even be detected across event types because the scope is based only on the platform.

  • We want to detect anomalies that are relevant to files in a cloud file-sharing application (such as exfiltration from the cloud), but do not want to include data about files on an endpoint. Using the subject and landscape context elements, we can target activities that happen to a file entity in a cloud file-sharing application.

    In this example, we could also use the platform element to further identify which application a detected anomaly targeted. We could even compare the rates of anomaly occurrence between different platforms in the same landscape (such as two applications in the cloud).

Search, Reporting, and Dashboards

Like any other fields, context elements can be used to drill into your data. As part of the log data, they're available for use by queries, reports, and other features. But because context elements can serve as a categorization method, the filtering capabilities they provide ensure accuracy on a global level while still enabling a granular filtering experience.

Consider the following examples:

  • Create a report from information that comes from a specific product category (such as EDRs).

  • Search for events that come from a specific platform (such as Unix).

  • Filter events that are about a specific subject (such as emails).

Context Elements in Interfaces

A single event can contain multiple context elements that compliment each other. By design, each element adds a separate, discreet piece of information or context that helps build a comprehensive picture of an event. This layered approach allows the context elements to remain independent, yet work together. Because the interfaces are tied to the context elements, field compliance can be enforced for existing events and content (such as parsers or event builders) can be created consistently for new events. For more information, see Common Information Model Interface.