About DSM

● Event: a message that is received and processed from a device on your network,
and is a log of a particular action on that device. In simple terms a single log entry
can be considered as an event.
○ After the events are collected and before the correlation can begin, individual
events from your devices must be properly normalized. Normalization means
to map information to common field names, such as event name, IP
addresses, protocol, and ports.
● A log source is any external device that is configured to either send events to IBM
QRadar system.
● Log source type defines the type of a log source. E.g. Arista switches/EOS. Each
Arista switch sending logs to qRadar is a log source.
● A Device Support Module (DSM) is a code module that parses received logs/events
and converts them to a standard taxonomy format that can be displayed as output.
Each log source type has a corresponding DSM.
● custom log source type: If QRadar does not provide a DSM for a device type, you
can use a custom log source type.
● Log source extensions document
○ You can use the extension document to correct a parsing issue or override
the default parsing for an event from an existing DSM.
○ When a DSM is not available, it can be used to define parsing of logs/events
for a device type.
○ It is an XML formatted document. Only one extension document can be
applied to a log source type.
○ It consists of 2 sections
■ Pattern
● Defines Regular expressions associated with field names
within a log/event. These patterns are referenced later multiple
times within the file.
■ Match groups
● An entity within a match group that is parsed, for example,
EventName, and is paired with the appropriate pattern and
group for parsing. Any number of match groups can appear in
the extension document.
● In simple terms I think it is the matched value(s) from a pattern
● Event Categories:
○ Event categories are used to group incoming events for processing by
QRadar.
○ The event categories are searchable and help you monitor your network.
○ Events are aggregated into high-level categories and low-level categories.
Each high-level category contains low-level categories and an associated
severity level and ID number.
○ Each event is assigned to a specific high-level category. There are some ~22
predefined high-level categories. E.g. Authentication, malware, policy, audit,
control, etc
● QID: QID is also referred to as Event categorizations. It is an internal record for the
event/log, with a number that stores extra metadata that might not exist verbatim in
 the raw event/log data, such as a human-readable name and description, a severity
value, or a low level category assignment. Low-level categorization and severity
are useful for search and rule definitions.
● DSM extracts Event ID and category values from events/logs. These are then used
to look up the mapped QID.
● Event Mapping: It represents an association between an event ID & category values
combination and a QID record.
○ One can create/import new QIDs, modify existing QIDs or export existing
QIDs using a shell script by logging into root CLI through SSH.
● Property:
○ There are two types of property
■ System property: defined by Qradar. E.g. user name, source ip,
destination ip, event id, etc. DSM tries to extract values from logs for
these system properties.
■ Custom property: any other value that one wants to extract from a
log so that can be used in rules or search.
○ Qradar may not be interested in knowing all values in a log.
○ Qradar saves logs content and values extracted for properties.
● DSM Editor
○ One of the use cases of the DSM editor is to define things for a new log
source type for which a DSM is not already available. It can be used to extract
fields (using regEx, etc) from a log format, define custom properties for
event/log, categorize events, and define new QID definition.

Referrenses
1. https://youtu.be/KF40bba_kp0
2. https://www.ibm.com/support/pages/node/6258039