Skip to main content

Security ContentExabeam Security Content in the Common Information Model

Common Information Model Interface

The interface of the common information model is a multi-layered structure that helps enforce the information model schema. Each layer defines the information necessary for a well-formed event that is in compliance with the common information model. Through this multi-layered structure, the information model can impose conventions on activity types and fields, enforce field compliance, simplify the creation of custom content, and provide extensibility for future expansion.

CDI Methodology

At each level of the common information model, field information is defined with a CDI classification. CDI stands for Core, Detection, Informational. The term is used to indicate how field compliance is enforced for a given interface. Fields are assigned a value (either 1 or 0) for each CDI element and the combination of these values indicates the compliance level that will be enforced in order for the field to be compatible with downstream Exabeam processes, such as searching, displaying, or analyzing log data.

  • Core – The field is required for a log to be parsed meaningfully in Advanced Analytics and without it the log cannot be used. Examples of core fields include time, product, subject, file_name.

  • Detection – The field is necessary for detecting a specific type of risk. Without this field, an Advanced Analytics detection capability that requires the field will not function properly. Examples of detection fields include process_command_line, file_path.

  • Informational – The field is not required or necessary for Advanced Analytics, but is provided in the log. Examples of informational fields include host, process_id.

Note

CDI methodology is not currently used to enforce field compliance for Data Lake.

In the Common Information Model Library, the CDI values are represented like the following:

CDIsample.png

To preserve consistency, field definitions are global, regardless of the interface they are assigned to. Field enforcement is realized by comparing event content to the interface schema.

Note

For custom fields that are not enforced as part of the CDI methodology, assign the designation other.

Parser Calibration Tiers

To provide visibility into how well parsed data is aligned with the common information model, the CDI methodology is leveraged in a capability called Exabeam Parser Calibration. As a measure of data quality, calibration tiers are calculated post-event building and indicate how closely the extracted data complies with the CDI classifications.

For Exabeam applications that display Exabeam Parser Calibration tiers in the UI (such as Outcomes Navigator), the list below defines each tier and provides some insight about how to increase parser compliance, if necessary.

  • Tier 1 – The log is parsed and an event has been built that includes more than 70% of CDI fields.

  • Tier 2 – The log is parsed and an event has been built but it contains less than 70% of the CDI fields. Consider examining the parser in Log Stream to increase the extraction of field values required by the CDI methodology. It may be helpful to consult the Common Information Model Library to determine what additional fields are required. In particular, see the Subject Interface and the Activity Type Interface pages of the library.

  • Tier 3 – The log is parsed but it does not meet the CDI-required criteria to build an event. In Log Stream, examine the event builder definition to ensure that it is configured correctly to build an Exabeam event. Also validate that the parser is extracting the field values from the raw log that are necessary to satisfy the CDI methodology. Consult the Common Information Model Library to determine what fields are required. In particular, see the Subject Interface and the Activity Type Interface pages of the library.

  • Tier 4 – No parser is available to parse the log.

Interface Layout

The layered structure of the common information model interface provides a simple, scalable way to track and manage the attributes related to events. Each layer of the interface inherits the configuration of the previous layer. Together they create a complete picture of an event, according to the common information model.

Let's examine the interface layers by considering the example of an email-send event, as shown in the image below.

hierarchy.png

  • Universal – This interface defines a set of global fields. These are fields that are required for every event, regardless of the type of event. It includes fields like time, vendor, product, and other context elements. See the Universal Interface in the Common Information Model Library for a comprehensive list of universal fields.

  • Subject –This core interface defines the subject element. It details the minimum field requirements necessary to identify the subject across possible logs. By design, the subject is maintained as a minimalist interface, including only fields that are fundamental to representing the entity. In the email-send example, the email subject interface includes fields like sender, recipient, email_subject, and attachments. See the Subject Interface in the Common Information Model Library for a comprehensive list of subjects and their minimum required fields.

  • Activity Type –This secondary interface defines the activity type element. It describes the specific fields required for a given activity when it's performed on the subject. This interface is also minimalist by design. In the case of the email-send example, this interface is empty because there are no unique fields for the activity type that are not already inferred from the subject. If however, the activity type was email-copy, there could be a unique field like scr_email in this secondary interface. See the Activity Type Interface in the Common Information Model Library for a comprehensive list of activity types and their minimum required fields.

    Note

    In the Common Information Model JSON file, this interface is currently referred to as the Event Type interface because it is represented by the activity_type + the outcome.

  • Extension –This interface defines any additional context elements that help describe the event. The extension layer preserves fields that were not essential to describing the subject or activity type, but are still represented in the log source. Extensions can contain two definitions. One contains schema fields, which are the fields required for any log from a given data source. The other definition contains activity type mapping, which includes the fields required for a specific activity type from a given data source.

    For the email-send example, the extension interface includes a product element. In this case product, m365 audit log, adds fields like src_ip and object that further define the event. See the Extension Interface in the Common Information Model Library for a comprehensive list of extensions and their minimum required fields.

Because the interface layers inherit configurations from each other, but don't necessarily overlap, enforcement can be performed in steps, with compliance being enforced independently within each layer. And because the interfaces are tied to the context elements, both existing event enforcement and new content creation become a simple matter of adhering to the common information model interface structure.