IBM C1000-162 key terms

A QRadar event or flow record that matches a rule with an offense response, creating an alert that aggregates related events into an investigation record with severity, magnitude, and assigned user.

A computed score on an offense that increases with event count, severity, relevance, and credibility, helping analysts prioritize which offenses to investigate first.

A rule-building-block weight that estimates how trustworthy a detection is, based on the reliability of the source or event category contributing to an offense.

A building-block weight expressing how significant an event is to the organization's environment, often derived from asset importance or network context.

A building-block weight describing the potential impact or danger of the activity detected, independent of how many times the event occurs.

The configurable period, in days, during which closed or inactive offenses remain stored before automatic deletion, balancing investigation history against database growth.

A setting that links a new offense to an existing open offense when they share the same source or destination IP, reducing duplicate alerts for one ongoing incident.

A note or comment attached to an offense by an analyst, preserving investigative context such as findings, actions taken, or handoff details for other team members.

The act of resolving an offense with a reason code, removing it from the active queue while retaining its record for reporting and audit purposes.

The rule or contributed-data origin that generated an offense, shown in the offense summary so analysts know which detection logic fired.

The configured action a rule takes when its tests match, such as creating an offense, sending an email, dispatching to syslog, or generating a custom event.

A logical test composed of conditions on events or flows that, when satisfied, triggers one or more responses such as offense creation or notification.

A reusable rule that only contributes to other rules and does not itself generate offenses, letting analysts centralize shared logic and weighting.

A single condition inside a rule, such as matching an event property, a source IP, or a building block, that must evaluate true for the rule to fire.

A user-created rule built in the Rule Wizard or Rule Editor from event, flow, or offense conditions, as opposed to a default content rule.

A folder-like container that organizes rules by purpose or log source, controlling which rules are enabled and simplifying administration.

A rule condition that compares an event count in the current interval against a baseline or threshold over time, detecting volume anomalies.

A QRadar capability that learns normal event and flow volume patterns per property and flags deviations, often feeding rules that create offenses.

A named collection of values, such as IPs, users, or domains, stored in memory and usable in rules and searches to include or exclude known entities.

A named key-value lookup table stored in memory, used in rules and searches to enrich or filter events by associating keys with additional attributes.

A list of entities or behaviors that analysts monitor actively, often implemented with reference sets and rules that raise offenses when matches occur.

The proactive, hypothesis-driven search through retained events, flows, and offenses to uncover activity that existing detections did not catch.

A hunt structured around a testable statement about adversary behavior, such as a specific technique or tool, that the analyst then validates or refutes with data.

Associating detection rules and hunts with adversary tactics and techniques so coverage gaps and priorities can be analyzed systematically.

Ariel Query Language, the SQL-like syntax used in QRadar to search events, flows, and offenses, supporting SELECT, WHERE, GROUP BY, and time-range clauses.

The QRadar data store that holds normalized events and flows on which AQL searches run, with retention governed by storage policies.

A stored AQL query with its time range and grouping, reusable for recurring investigations, reports, and dashboard widgets.

The configured duration that events or flows remain searchable in the Ariel database before being purged, affecting how far back hunts can look.

A scheduled or on-demand output that runs saved searches and layouts to deliver formatted results, such as offense summaries, to recipients.

A collection of widgets displaying live or saved query results, such as offense counts or top sources, arranged for at-a-glance situational awareness.

An individual panel on a dashboard, configured with a query, visualization type, and refresh interval to show a specific metric.

Assigning a dashboard to user roles or groups so team members see the same view, with permissions controlling who may edit it.

A set of permissions assigned to a user account that determines which QRadar functions, data, and dashboards the user can access or modify.

A logical partition in a multi-tenant deployment that isolates a customer's data, users, and offenses from other tenants on shared infrastructure.

The structured process of triaging an offense: reviewing contributing events, checking asset context, assessing magnitude, annotating findings, and closing with a reason.

Adjusting rules, building block weights, or reference sets to suppress benign activity that repeatedly triggers offenses, improving signal quality.

A configured source of events, such as a firewall or server, whose parsing and normalization determine how its data appears in searches and rules.

The process of mapping raw log fields to QRadar's common event model so that rules and searches can work consistently across different vendors.