QRadar SIEM V7.5 Admin key terms

The ordered sequence of QRadar components that an event passes through from ingestion to storage: collector, event processor, and magistrate, plus the data node path in multi-node deployments. Each stage adds parsing, correlation, or indexing before the event becomes searchable.

A QRadar appliance or service that receives raw events from log sources, applies the log source's parsing routines, and forwards normalized events to the event processor. Collectors can be dedicated, combined with processing, or virtual.

The QRadar component that receives parsed events from collectors, runs custom rules and building blocks against them, and forwards results to the magistrate for storage. It holds the rules engine and contributes to offense creation.

The QRadar component that stores events in the Ariel database, maintains indexes, and answers searches and reports. It also stores offenses and their associated annotations. In distributed deployments it runs on a dedicated host.

The proprietary QRadar data store that holds events and flows in time-partitioned databases. It supports fast indexed searching and enforces retention through partition deletion rather than row-by-row deletion.

A QRadar package that defines how to identify, parse, and normalize events from a specific device or application family. The DSM maps vendor-specific fields into QRadar's Common Event Format fields so rules can work across products.

A syslog-based event format with a header and key-value extension fields that QRadar can parse natively. Many third-party devices emit CEF, allowing ingestion without a vendor-specific DSM.

A custom XML document applied to a log source that adds or overrides parsing patterns, identifies unknown event types, and can rewrite fields. Extensions are used when the installed DSM does not parse a device's events correctly.

A configured representation of a device or application that sends events to QRadar, defined by its type, protocol, identifier, and enabled state. Each log source is bound to a DSM and, optionally, an extension.

The value QRadar uses to match incoming events to the correct log source, typically an IP address, hostname, or file path. A mismatch between the identifier and the actual sender causes events to land on the wrong or an unknown log source.

A placeholder bucket where QRadar stores events that arrive but cannot be matched to a configured log source. A high volume of unknown events usually signals an identifier mismatch or an unconfigured sender.

A QRadar feature that detects new event and flow sources, suggests a log source type, and lets an administrator create the matching log source. It reduces manual configuration but should be reviewed to avoid misclassified sources.

A standard protocol for forwarding log messages over UDP or TCP, commonly on port 514, which QRadar accepts for many integrations. Reliability differs between UDP and TCP, and TLS-wrapped variants are supported for encrypted transport.

The process by which QRadar merges duplicate or near-duplicate events from the same source into a single stored event with an incremented count. Coalescing reduces storage use but can hide individual event timing.

A field QRadar extracts from raw event or flow payloads using a regular expression or JSON/XML expression, then stores for searching, rules, and reports. Custom properties are defined per log source type and appear in the event details.

A parsed value taken from the event payload and mapped to a QRadar field, such as username or source IP. Extraction may come from the DSM, a log source extension, or a custom property definition.

The association between a vendor-specific field in a log source and a normalized QRadar field used by rules and searches. Correct mapping is essential for correlation to function across heterogeneous devices.

A pattern language used in QRadar custom properties and log source extensions to capture fields from raw payloads. Poorly anchored or overly greedy expressions cause performance problems and incorrect extraction during high event rates.

A user-defined test-and-action rule that evaluates events or flows against conditions and can generate offenses, annotations, or notifications. Rules are the primary mechanism for turning normalized data into actionable alerts.

A reusable rule fragment that evaluates to true or false and is referenced by other rules instead of duplicating conditions. Building blocks simplify maintenance but add evaluation cost, so they should be kept efficient.

A QRadar alert generated when rule conditions are met, aggregating related events and contributing rules into a single investigative record. Offenses carry severity, magnitude, status, and assigned users.

A score QRadar computes for an offense that reflects the number and severity of contributing events and rules. Magnitude rises as related events accumulate and helps analysts prioritize among open offenses.

The configured period for which closed or inactive offenses remain in the system before deletion. It is separate from event retention and is tuned to balance investigation history against database growth.

The response a rule triggers when its conditions match, such as creating an offense, adding to an existing offense, sending an email, or running a custom script. Actions determine how detected activity is surfaced to analysts.

The tree of network objects and groups in QRadar that assigns names and classifications to IP ranges. It drives asset identity, flow direction, and rule conditions that reference internal or external networks.

A configured device, such as a router or firewall, that exports flow data to QRadar via NetFlow, sFlow, IPFIX, or a similar protocol. Flow sources populate traffic analysis and are separate from event log sources.

A flow export protocol originated by Cisco that reports summarized connection metadata such as source, destination, ports, and byte counts. QRadar accepts several NetFlow versions and maps them into normalized flow records.

A QRadar record describing a discovered host, including its IP addresses, open ports, services, and identity information. Asset data enriches events and flows and can be updated manually or through vulnerability scanners.

A logical partition in QRadar that separates data, users, and configurations for different organizations or business units. Users are granted access to one or more domains, and data is invisible outside assigned domains.

A customer or organizational unit in a multi-tenant QRadar deployment, implemented through domains and tenant-specific user roles. Tenants see only their own data while sharing the underlying infrastructure.

A set of permissions in QRadar that controls which functions and tabs a user can access, such as rules, administration, or offense management. Profiles are assigned to user roles and combined with domain access.

A named assignment that pairs a security profile with one or more domains for a user account. Roles determine both what a user can do and which data the user can see.

The mechanism QRadar uses to verify user identity, either through its local user database or an external source such as LDAP, Active Directory, or SAML single sign-on. Authentication settings are configured centrally for the deployment.

A QRadar deployment pattern in which a standby appliance mirrors a primary host and takes over if the primary fails. HA pairs require synchronized configuration and are managed through the HA cluster view.

The automatic or manual switch of services from a failed primary appliance to its HA standby partner. After failover, the former standby becomes active and the original host must be repaired and resynchronized.

The process of capturing QRadar configuration and data so a deployment can be rebuilt after loss. Backups include configuration and, optionally, offense and event data, and are restored through the backup and restore interface.

The plan and procedures for rebuilding QRadar after a site-wide or unrecoverable failure, typically using configuration backups and reinstalled appliances. It differs from HA, which handles single-host failure.

The rule set that determines how long events and flows remain searchable before their Ariel partitions are deleted. Retention is expressed in time buckets and constrained by available disk space.

An optional QRadar appliance that stores a portion of event and flow data and participates in searches, extending storage capacity and search throughput. Data nodes are managed from the primary host.

The practice of adjusting QRadar components, rules, parsing, and storage to handle event volume within capacity limits. It includes reviewing expensive rules, tuning coalescing, and monitoring EPS against licensed limits.

The rate at which QRadar receives and processes events, used for licensing and capacity planning. Sustained rates above licensed or hardware capacity cause dropped events and delayed searches.

The QRadar interface for searching, filtering, and analyzing events, including real-time and historical views. It is the primary tool for verifying that log sources are sending and parsing correctly.

A routine inspection of QRadar appliance status, including services, disk usage, replication, and event rates. Regular health checks catch capacity and service problems before they cause data loss or outages.

The practice of reading QRadar component logs, such as those under the log directory, to diagnose parsing failures, service errors, and connectivity issues. Logs are often the fastest route to root cause during troubleshooting.