IBM C1000-150 key terms

A single QRadar installation managed as one unit, consisting of one or more hosts that share a common configuration and data store, identified by a deployment ID and managed from an admin console.

The QRadar host that provides the user interface, handles configuration and administrative tasks, and stores rules, reports, and other system settings; it may also run event and flow processing on small deployments.

A QRadar host or component that receives events from Event Collectors, stores them in the Ariel database, and runs correlation rules and custom rules against those events to generate offenses.

A QRadar component that receives raw event data from log sources, parses and normalizes it, and forwards it to an Event Processor for storage and correlation; it does not itself run rules.

A QRadar component that collects and stores network flow data from flow sources and Flow Collectors, enabling traffic analysis, top talkers reports, and flow-based rules.

A QRadar host that receives flow data from flow sources such as routers and switches and forwards it to a Flow Processor, distributing collection load across the deployment.

Any QRadar host other than the Console, such as an Event Processor, Event Collector, Flow Processor, or Data Node, that is added to a deployment and centrally administered from the Console.

A numeric identifier assigned when a QRadar deployment is created; it must match across all hosts in the deployment and is used by services and licenses to recognize which hosts belong together.

Two QRadar hosts configured so that one actively processes data while the other stays synchronized as a standby, taking over automatically if the active host fails, preserving event and flow continuity.

A QRadar configuration in which a secondary deployment receives replicated configuration and data from a primary deployment so operations can resume at another site after a major outage.

A defined representation of a device or application that sends event data to QRadar, including its identifier, protocol, parsing configuration, and associated log source extension or DSM.

A QRadar package that knows how to identify, parse, and normalize events from a specific device or software product, mapping vendor fields to QRadar's common event taxonomy.

A custom XML-based configuration that adds or overrides parsing for a log source, typically used when the vendor DSM does not correctly extract fields such as usernames, source IPs, or event names.

The unique value, often an IP address or hostname, that QRadar uses to match incoming events to the correct configured log source, especially when multiple sources share a protocol.

The QRadar event pipeline stage that groups events with identical key properties, such as log source, event name, and source IP, into a single stored record with an occurrence count to reduce storage.

The process of converting raw vendor-specific event fields into QRadar's common information model so that events from different products can be searched, correlated, and reported consistently.

A user-defined field extracted from raw event payloads using a regular expression or JSON expression, allowing events to be enriched and searched by values the base DSM does not capture.

A pattern language used in QRadar log source extensions, custom properties, and rules to match and capture specific text within raw event payloads or flow content.

The ordered set of processing stages a QRadar event passes through after collection, including parsing, normalization, coalescing, custom rules, and storage in the Ariel database.

The QRadar data store that holds normalized events and flows, queried through the user interface, Ariel Query Language, or the REST API for searches, reports, and rule tests.

A SQL-like query language used in QRadar to search, filter, group, and aggregate events and flows in the Ariel database, including joins across event and flow views.

A QRadar record created when correlated events or flows meet the conditions of a rule, aggregating related activity with severity, magnitude, involved sources, and annotations for analyst investigation.

A logical test in QRadar that evaluates events or flows, optionally across a time window, and can trigger responses such as creating an offense, sending an email, or running a custom action.

A user-created rule written in the Rule Wizard or rule editor that tests event or flow conditions and defines actions, distinct from the built-in rules shipped with QRadar.

A reusable rule fragment that tests a condition and returns true or false; it is referenced by other rules to keep logic modular and maintainable instead of duplicating tests.

The response QRadar performs when a rule's conditions are met, such as creating or contributing to an offense, generating an email, syslogging to another system, or executing a custom action script.

A computed score in QRadar that reflects how significant an offense is, derived from severity, relevance, and the number and rate of contributing events, used to prioritize analyst work.

A configurable value assigned to a QRadar rule or offense that expresses how serious the detected activity is, contributing along with relevance to an offense's magnitude.

A note, comment, or status change attached to a QRadar offense by an analyst, recording investigation findings, assigned ownership, or closure rationale for audit and collaboration.

A named collection of values, such as IP addresses, usernames, or hashes, that QRadar rules and searches can test against, commonly populated by threat intelligence feeds or custom lists.

A named key-value lookup table in QRadar used to enrich events and flows or to drive rule logic, for example mapping an IP address to an asset owner or a risk category.

A QRadar record describing a discovered or manually defined host, including its IP addresses, open ports, installed services, and assigned business context such as owner or importance.

A grouping of assets in QRadar that share characteristics, used to apply common business context, vulnerability scanning results, and policy behavior to many hosts at once.

A weakness record imported into QRadar from a scanner such as a network vulnerability assessment tool, correlated with assets and offenses to show which exposed hosts carry known risk.

An external or internal source of indicators, such as malicious IPs or domains, that QRadar ingests to populate reference sets and drive rules that flag communication with known-bad infrastructure.

A logical partition in a QRadar deployment that isolates data, users, and configuration for different customers or business units while sharing the underlying hardware and services.

A QRadar permission set that determines which tabs, networks, and actions a user account can access, often combined with security profiles and tenant assignments to enforce least privilege.

The QRadar programmatic interface that exposes configuration, offense, and search endpoints over HTTPS, used to automate administration, integrate with ticketing systems, and pull data into other tools.

A user-defined script or executable that QRadar runs in response to a rule or offense, often used to enrich data, notify external systems, or trigger automated remediation workflows.