Custom Event Properties:
QRadar is able to run advanced analytics and trigger Offenses across multiple data sources because it is able to normalize data from a variety of sources. By default, QRadar normalizes data it ingests from the event payloads and then uses that information for correlation, searches, reports and to populate the ‘Log Activity Tab’.
This initial normalization is done by Device Support Modules (DSMs) and we have hundreds of DSMs and they are each able to normalize data from a different source. DSMs parse a standard set of fields including, usernames, source IP, destination IP, and ports from the event payloads. However, they do not parse all of the data in every payload and some event sources send unique information that is important to the administrator.
Extracting these unique fields are where Custom Event Properties (CEPs) come into play. CEPs enable administrators to use regex to extract data from event payloads and use that data to populate the user interface, run reports, or run searches against these specific values.
QRadar users can create their own custom properties in QRadar and those can be identified in the UI as they are all labeled with the term (custom) in the ‘Log Activity Tab’. These values must be enabled and optimized to populate the user interface and be leveraged in searches (1).
CEPs are also delivered to IBM QRadar customers via Content Packs on the IBM Security App Exchange (Here). Over time, as the IBM team developed CEPs, there were some inconsistencies in the naming schema and now we’re updating the IBM produced CEPs to ensure consistency across devices. See image below for an example of the inconsistencies.
Re-Baselining Overview
In order to reduce inconsistencies all redundant CEPs will be ‘re-baselined’ to a common schema. Redundant CEPs will be merged into a single ‘alias’ CEP. See below for an example of a ‘pre-baselined’ CEP re-baselined into an ‘alias’ CEP.
The update to the CEPs will occur automatically as users upgrade to QRadar 7.4.3. The update will only impact IBM produced CEPs. CEPs created by customers WILL NOT be impacted. The update to CEPs will only happen once. For example, if a customer upgrades from 7.4.2 to 7.4.3 the CEPs will be updated but they will not be updated again when customers upgrade from 7.4.3 to 7.4.4.
The pre-baselined CEPs will be merged and linked to the ‘alias’ CEP and the pre-baselined CEPs will still exist in the backend of QRadar. Therefore, there should be no impact to any scripts or apps that are reliant on the ‘pre-baselined’ CEPs.
In addition to the merging of CEPs there will also be several other changes made including case modification, renaming, and merging. See below for examples:
Re-baselining Implementation
This re-baselining will be noticeable in three key places where users interact with CEPS:
(1) DSM Editor, (2) CEP Window, and (3) Rules Wizard.
DSM Editor:
Pre-baselined properties will be hidden and linked to an alias property. Only alias properties will be visible in the DSM Editor.
CEP Window:
Pre-baselined properties will be hidden and linked to an alias property. Only alias properties will be visible.
Rules Wizard:
In the Rules Wizard both the pre-baselined names and alias names are visible. Customers should use the alias property names in their rules. Pre-baselined properties that were optimized to be used in rules before the baselining are visible and optimized. Pre-baselined CEPs that were not optimized for rules before the baseline are not visible in the Rules Wizard.
Please note that when content from QRadar versions earlier than 7.4.3 is imported to 7.4.3 the imported content will be transformed to our new schema upon import.
Please reach out with questions!
Thanks,