Multi-Tenant Retention and Cross-Domain Visibility
A managed security provider runs one QRadar console with four Event Collectors for three customers. Customer A requires 12-month retention for contract and regulatory reasons, Customer B requires 90 days, and Customer C accepts 30 days. Total ingestion is about 2,000 EPS, with Customer A contributing 1,200. Eight analysts serve all three customers from a shared pool, and two junior analysts are assigned only to Customer C. A recent incident exposed that a Customer C analyst could see offense details containing Customer A hostnames in a shared dashboard. The provider wants to keep one console for cost reasons but must demonstrate tenant separation during a customer audit next month. Disk is sufficient for the aggregate 30-day requirement but not for 12 months of all tenants' raw events.
1. Propose a domain and role design that separates tenant visibility without forcing three separate consoles.
Read the worked answer
I would use QRadar domains as the primary tenant boundary and assign each log source to the correct domain, then make analyst roles domain-scoped rather than relying on dashboard edits. Customer C analysts get a role limited to Customer C's domain; shared senior analysts get a multi-domain role only where the contract allows it. Shared dashboards must be rebuilt as domain-aware or duplicated per tenant, because a dashboard that aggregates across domains will leak by design. I would also review offense access: an offense created in Customer A's domain must not appear in a global view shown to Customer C staff. The trade-off is administrative overhead: every new log source, rule, and report needs a domain decision, and misassignment is the most likely failure. To make that auditable, I would define a naming convention and a change checklist, then test with a Customer C account attempting to search Customer A data.
2. Customer A needs 12 months of retention but disk cannot hold all tenants for that period. What retention approach would you recommend?
Read the worked answer
I would avoid promising uniform 12-month retention on the shared store and instead match retention to the requirement and the evidence value. First, confirm what Customer A actually needs to retain: raw events for all sources, or offense and investigation records plus selected high-value logs. If raw events are mandatory for a subset, dedicate storage or a separate event processor to Customer A so its retention does not consume the shared pool needed by B and C. If the requirement is evidentiary rather than searchable, export or archive the required data with integrity controls and document restore time. I would not silently shorten retention and tell the customer it is covered. The audit test is whether a requested event from month 11 can be produced within the contracted time. If the current architecture cannot do that, the options are added storage, scoped retention, or a contractual renegotiation, and the provider should choose explicitly rather than let disk pressure decide.
3. The two junior analysts need to investigate Customer C offenses. What access controls and monitoring would you put around that access, and what would you refuse?
Read the worked answer
I would give the junior analysts a role scoped to Customer C's domain with the minimum permissions needed to investigate and close offenses, not administrative rights to log sources, rules, or retention. Their searches should be limited to Customer C data, and any shared case notes should avoid copying Customer A identifiers. I would add audit logging of their searches and offense access, with periodic review, because domain separation is a configuration control and configuration drifts. I would refuse two requests: a shared super-admin account used by all analysts, and a temporary expansion into Customer A's domain without a named case, approval, and time limit. The reason is that separation must survive convenience pressure, not just the audit. If a genuine cross-tenant incident requires visibility, I would create a documented break-glass process with two-person approval and post-use review, then remove the access immediately.