Common Information Model Impact on Data Lake Categorization for Search and Reporting

The introduction of the common information model represents a shift in the way data is classified across Exabeam products. It's important to note the following points about the transition to common information model categorization:

No classification information has been lost in the new structure.
Components may be named differently or be covered by a different context element, but no relevant categorization capabilities have been removed. In fact, categorization granularity has been deepened and expanded.
All existing security content has been migrated.
You don't need to migrate any of your existing security content in order to begin using the common information model. All parsers, event builders, models, rules, and fields have been migrated for you, including any existing custom content.

The common information model is designed around a central task: defining events. It uses a layered approach that relies on a hierarchy of context elements to form a minimalist but detailed structure. This contextual granularity ensures accurate and consistent event classification. The layered approach also provides a framework that allows for future augmentation across all data and metadata elements within the common information model.

For background information about the benefits of, and the rationale behind the common information model, see Common Information Model.

Legacy Structure vs. Common Information Model

In the legacy categorization structure for Data Lake, data is classified either by exa_category or on the basis of the following three components: exa_activity_type, exa_device_type, exa_outcome

This legacy categorization structure is internally inconsistent, does not extend to other Exabeam products, and cannot encompass the context elements that are so central to security functions. The common information model structure introduces the concept of context elements to Data Lake. For detailed information about the context elements, see Common Information Model Context Elements.

The chart below shows a high level view of how the common information model context elements map to the legacy categorization components.

Common Information Model Context Element	Description	Data LakeComponent
Subject	Identifies the entity being targeted by an event. Examples include `user`, `file`, `email`, `process`, `endpoint`. Use to query a type of entity. Examples: Show all events that occurred on files. Create a report on activities for a process.	`exa_activity_type` `exa_device_type` `exa_category`
Activity Type	Identifies the type of operation represented in the event. Examples include `file-write`, `process-create`, `user-password-modify`, `endpoint-login`. Use to query events of a similar activity and subject. Examples: Find all file-delete events Generate a report on peripheral_storage-insert activities.	`exa_activity_type` `exa_category`
Outcome	Identifies the result status of the event. Outcome options are `success` or `fail`. Use to query whether an activity had its intended effect.	`exa_outcome`
Vendor	Identifies the owner of the product that recorded the event.	`vendor` field
Product	Identifies the service or application that recorded the event. Examples include `falcon`, `event viewer - security`, `aws cloudtrail`. Use to query what was monitored or triggered by a product. Examples: Show all events generated by the palo alto ngfw. Show what is contained in the event viewer security logs.	`product` field (partially)
Product Category	Identifies an umbrella category for the product. Examples include `email`, `firewall`, `siem`. Use to query what was monitored or triggered by a general type of product. Examples: Create a report on data from all firewalls. Show data collected by all SIEMs.	`exa_device_type` `exa_category`
Platform	Identifies the virtual environment or application in which the event occurred. Examples include `windows`, `okta`, `o365`, `github`. Use to query activity in specific environments. Examples: Filter a search to show all activities that took place in a Windows environment. Generate a report on activities that occurred on Zoom.	`product` field (partially)
Landscape	Identifies an umbrella category for the platform. Examples include `cloud`, `endpoint`, `database`, `vpn`. Use to query activity in general types of environments. Examples: Show activity on file sharing applications. Show all events from endpoints.	`exa_device_type` `exa_category`

Exa_Category Mapping to Common Information Model Context Elements

The following table details how each legacy exa_category maps to specific common information model context elements. For some sample queries, see the section below the table called Sample Queries – Legacy vs. New Context Elements

Data Lake Category	Common Information Model Context Element
Account Management	`subject:"user"`
Account Switch	`activity_type:"user-switch"` Note Activity_type is represented by the combination of subject + activity.
Active Directory	`platform:"microsoft ad"`
Application	`subject:"application"` Note The `application` field is falling out of use in favor of the more accurate `platform` field.
Audit Change	`subject:"audit_policy"`
Authentication	`activity:"authentication"`
Badge	`subject:"physical_location"`
Configuration Change	`subject:"configuration"`
DHCP	`subject:"dhcp"`
DLP	`product_category:"dlp"`
Database	`landscape:"database"`
Endpoint	`landscape:"endpoint"`
Failed Logons and Lockouts	`(activity:"login" AND outcome:"fail") OR activity_type:"user-lock"`
File	`subject:"file"`
Logout	`activity:"logout"`
Network	`landscape:"network"`
Network Alert	Deprecated
Print Activity	`subject:"printer"`
Privileged Access	Deprecated
Security Alerts	`activity_type:"alert-trigger"` Note Activity_type is represented by the combination of subject + activity.
System Event	Activity included in this category is represented by a range of `landscape` values. The `landscape` entity is an umbrella entity that can capture a broad scope of activities happening on various platforms. Examples: `landscape:"cloud"`, `landscape:"endpoint"`, `landscape:"database"`, `landscape:"vpn"`.
VPN	`landscape:"vpn"` or `subject:"vpn"` Note Landscape VPN captures a broad scope of activities that happen on a VPN platform, whether or not the activity concerns the VPN itself. In contrast, Subject VPN is reserved for more granular activities that involve interaction with a VPN itself, such as logging in or out.
Web	`subject:"http"`
Windows Authentication	`activity:"authentication" AND platform:"windows"`

Sample Queries – Legacy vs. New Context Elements

The following table shows a few examples of what legacy queries look like when rewritten using common information model context elements.

Legacy Query	Common Information Model Query
`exa_category:"Network"`	`landscape:"network"`
`exa_category:"DNS"`	`subject:"dns"`
`exa_category:"Configuration Changes"`	`activity_type:"configuration-modify"`
`exa_category:"Account Management"`	`subject:"user"`
`exa_activity_type:"file/read"`	`activity_type:"file-read"`
`exa_device_type:"network/firewall"`	`product_category:"firewall"`
`exa_device_type:"database"`	`landscape:"database"`
`exa_outcome:"success"`	`outcome:"success"`

New Types of Filtering Made Possible by the Common Information Model

The following table shows how the new common information model context elements can be used to create some new types of queries that were not possible with the legacy categorization structure.

Common Information Model Query	Description
`platform:"windows"`	Queries everything from all Windows systems.
`product:"event viewer - security"`	Queries everything from all security logs.
`subject:"peripheral_storage"`	Queries all activity that took place in peripheral storage.

Security ContentExabeam Security Content in the Common Information Model

Table of ContentsTable of Contents