Users are restricted by a process with five-day restrictions from most recent flagging time. When ingesting SSO provider logs and on-prem appliance logs, what rule design supports quick implementation and easy maintenance to detect restricted user logins?

• A. Use SOAR global context with TTLs and a job to rebuild/deploy the detection rule with updated list.
• B. Store flagged user identifiers in rule logic and manually maintain.
• C. Ingest user flags as custom enrichment fed into entity graph; use multi-event detection rule to find logins from flagged users.
• D. Store flagged users in a data table with TTL and row-based comparisons in rule.

Answer: (C)

The essential idea is to enrich each login event with the current flag status of the user and then correlate multiple events across sources to catch any login attempts by flagged users within the five-day window. By feeding user flags into a central entity graph as custom enrichment, every SSO and on‑premise log line carries up-to-date information about whether that user is restricted. A multi-event detection rule can then scan across events—across both log sources—and flag logins from those flagged users, within the five-day period since the most recent flag. This design scales naturally as flags change, because you simply update the enrichment data, not the detection logic itself. It also keeps maintenance light: adding or removing a user from restriction automatically affects future detections without rewriting rules.

Compared to other approaches, this method avoids frequent rule rebuilds when the restricted list changes, and it eliminates manual rule edits for each flagged user. Storing identifiers directly in rule logic requires constant manual updates and doesn’t scale. Using a data table with TTL and row-based checks works but bypasses the richer relationship modeling of an entity graph and can become more cumbersome to maintain for cross-event, cross-source detections.