Retention pressure on a mixed event and flow deployment with a data node
QRadar 7.5.0 deployment: EP1 and EP2 each have 16 TB of /store/ariel, one FP, and one 12 TB data node. Licensed at 25,000 EPS; peak is 22,000 EPS. Event retention is 12 months for all events and 6 months for flows. /store/ariel on EP1 is 89% used, EP2 is 84%, and the data node is 72%. Compliance requires 12 months only for payment-card events, 90 days for everything else. The security team uses 14 regex custom properties; two are marked for rule matching and one extracts a session token with millions of unique values. Searches over 30 days are slow and frequently hit the 10-minute timeout. The business refuses to lose EPS or add disk this quarter but will approve a data-node search role change. You are asked to propose retention and parsing changes.
1. What retention design keeps card-data events for 12 months while reducing /store/ariel pressure, and what should you not do?
Read the worked answer
Reasoning: the pressure is in Ariel event storage on the EPs, not in EPS. A single global 12-month policy is the main waste because only card events need 12 months. QRadar retention buckets let you keep a long retention only for a filtered subset, with a shorter default for everything else. Decision: set the default event retention to 90 days; add a retention bucket for the PCI log sources or a reliable PCI marker custom property with 12 months; set flows to 30-90 days if no flow-retention requirement exists; let the data node hold old data and enable it for distributed search. Do not delete files under /store/ariel, shrink partitions, or reduce EPS to create space; those actions risk corruption or data loss. Retention changes do not free space instantly: old buckets roll off through cleanup, so monitor /store/ariel weekly and confirm the cleanup job. Validate with Ariel searches for a 12-month PCI event and a 100-day non-PCI event.
2. Which custom property changes would you make first, and how do you confirm the search timeout is reduced?
Read the worked answer
Reasoning: 14 regex properties run on every event; the session-token property has millions of unique values, which bloats the Ariel index and slows searches more than it helps. The two properties used for rules should remain optimized only if their cardinality is low. Decision: remove or stop extracting the session-token property; if it must be retained for forensics, leave it in the raw payload and do not enable it for rule matching or search optimization. Keep actor, action, and result as low-cardinality properties; anchor regexes to the start of the payload or use a DSM/JSON parser so each event does not run multiple broad regexes. Confirm with the same 30-day search before and after and compare query runtime, /store/ariel growth rate, and EPS; check Ariel query logs for timeouts. Do not mark a high-cardinality property optimized just to make it searchable.